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ABSTRACT 


This  thesis  describes  an  Extensible  Markup  Language  (XML)  based  analysis  and 
comparison  method  that  could  be  used  to  identify  equivalent  components  of 
heterogeneous  databases.  In  the  Department  of  Defense  there  currently  exist  multiple 
databases  required  to  support  command  and  control  of  some  portion  of  the  battlefield 
force.  Interoperability  between  forces  will  become  crucial  as  the  force  structure 
continues  to  be  reduced.  This  interoperability  will  be  facilitated  through  the  integration 
of  these  command  and  control  databases  into  a  singular  joint  database  or  by  developing 
inter-communication  schemas  to  support  inter-database  communications.  The  first  step 
in  either  of  these  alternatives  is  the  identification  of  equivalent  components  among  the 
multiple  databases. 

This  thesis  describes  how  XML  can  be  used  to  facilitate  the  process  of  analyzing 
and  comparing  multiple  databases.  Each  step  of  the  process  is  described  in  detail 
accompanied  by  explanations  of  the  XML  tools/resources  required  to  execute  the  step 
and  rationale  of  why  the  step  is  necessary.  Detailed  graphics  and  examples  are  employed 
to  simplify  and  justify  the  step  by  step  explanations.  The  JavaScript  code  developed  as 
part  of  the  research  to  execute  the  XML  based  analysis  is  included.  This  thesis  concludes 
with  discussions  of  the  overall  value  of  this  XML  based  analysis  and  comparison  process 
and  of  potential  future  work  that  could  be  pursued  to  further  exploit  this  XML  analysis 
and  comparison  method. 
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I. 


INTRODUCTION 


A.  RESEARCH  OVERVIEW 

The  reason  for  this  research  is  to  examine  methods  that 
could  improve  interoperability  between  independently 
designed  Command,  Control,  Communications,  Computers, 
Intelligence  (C4I)  Systems.  Each  of  these  C4I  systems 
employs  a  database  to  control  and  maintain  its  C4I 
information.  The  means  to  facilitate  the  interoperability 
between  these  different  C4I  systems  will  be  by  exchanging 
the  data  from  their  individual  databases.  The  first  step 
towards  this  data  exchange  will  be  to  determine  what  parts 
of  the  individual  databases  are  similar. 

This  thesis  describes  a  method  that  can  identify  the 
similarities  between  C4I  databases.  It  will  employ 
Extensible  Markup  Language  (XML)  as  a  means  to  analyze  these 
C4I  databases  and  to  extract  portions  from  each  for  closer 
examination  and  comparison.  The  entire  analysis  and 
comparison  process  will  be  described  in  detail  and  executed 
using  actual  C4I  databases. 

B.  C4I  BACKGROUND 

Command,  Control,  Communications,  Conputers,  and 
Intelligence  (C4I)  systems  have  been  developed  and  continue 
to  be  developed  to  support  numerous  and  very  diverse 
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militairy  capabilities.  These  capabilities  include  mission 
planning,  battlefield  command  and  control,  logistics 
management  to  name  just  a  few.  Each  of  these  C4I  systems 
retains  large  and  complex  databases  that  store  the  data 
necessary  to  execute  its  mission  objectives.  For  example, 
the  Global  Command  and  Control  System  (GCCS)  Integrated, 
Imagery  and  Intelligence  (I^)  utilizes  the  Modernized 
Intelligence  Database  (MIDB)  to  store  weapons  systems 
characteristics  and  national/tactical  imagery  to  provide 
operational  commanders  enhanced  situational  awareness.  The 
Advanced  Field  Artillery  Tactical  Data  System  (AFATDS) 

employs  the  AFATDS  Database  to  retain  the  data  required  to 
support  fire  support  planning,  execution,  movement,  and 
support . 

Most  C4I  systems,  including  the  ones  described  above, 
are  often  called  "legacy"  systems.  This  is  because  they 

were  developed  several  years  ago  to  support  very  specific 
requirements.  These  legacy  systems  continue  to  be  refined 
over  the  years  to  expand  existing  functionality  and  to 

incorporate  new  capabilities.  As  the  amount  and  value  of 
data  assembled  and  employed  by  these  legacy  systems  grew,  it 
became  apparent  that  the  sharing  of  this  data  between 

multiple  C4I  systems  would  enhance  combined  arms  management 
and  increase  the  overall  effectiveness  of  force.  To  support 
this  data  sharing,  joint  databases  are  being  developed  that 
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can  interface  with  the  legacy  database.  One  example  of  a 
joint  database  is  the  Joint  Common  Database  (JCDB) . 

The  JCDB  supports  the  Army  Battlefield  Command  System 
(ABCS)  by  providing  consolidated  data  from  multiple  Army 
systems  to  support  development  of  a  Common  Tactical  Picture 
for  A3rmy  battlefield  commanders.  This  consolidated  data  is 
also  used  to  enhance  the  capabilities  of  the  legacy  systems 
by  sharing  the  information  awareness  of  each  legacy  system 
with  the  others . 

C.  OBJECTIVE  OF  THESIS: 

The  objective  of  this  research  is  to  identify  a  method 
(or  methods)  that  can  help  distinguish  and  identify  common 
data  elements  and  physical  schemas  between  dissimilar  C4I 
databases.  Extensible  Markup  Language  (XML)  is  errployed 
wherever  possible  to  facilitate  this  identification  task. 
Problems  related  to  this  identification  task  include: 

-  Databases  are  extremely  large:  The  JCDB  consists  of 
526  tables  including  315  look-up  or  reference  set  tables 
that  are  the  data  provider  library  to  columns  in  the  primary 
tables.  There  are  a  total  of  1257  columns  in  the  JCDB,  of 
which  1147  are  unique.  Others  appear  in  more  than  one  table 
[JDDOO] .  To  graphically  display  the  physical  schema  using 
entity  relationship  diagrams  would  take  over  350  pages. 

There  are  many  databases :  The  many  and  often 
dissimilar  databases  (like  the  ones  identified  earlier) 
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continue  to  evolve  and  change  to  incorporate  new  data  to 
support  new  functionality  and  remove  unneeded  data  that 
supported  antiquated  functionality. 

-  Database  Terminology  Variance:  Subject  matter  experts 
defined  terminology  that  specifically  related  to  C4I  system 
functionality  as  each  database  was  developed  independently. 
This  terminology  variance  can  impact  the  comparison  of 
dissimilar  databases.  The  terms  "Tank"  and  "Armored 
Vehicle"  can  be  used  to  identify  a  heavily  amored,  mobile, 
direct  fire  weapons  system.  The  term  "Tank"  can  also  be 
used  to  describe  a  water  storage  tank. 

Physical  Schema  Variance :  Physical  schemas  can  vary 
from  database  to  database  even  though  they  describe  the  same 
thing.  For  example,  the  following  figure  shows  two 
different  representations  of  the  same  object.  System  A 
describes  everything  in  one  object.  System  B  uses  the 
attributes  to  describe  the  object  in  different  lower  level 
objects.  As  a  whole,  physical  schema  A  and  physical  schema 
B  describe  the  same  object. 
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SYSTEM  A 


SYSTEM  B 


Car 

1 

1 

1 

Car 

Type:  GM 
Color:  Red 

1 

1 

1 

1 

1 

Type 

_ 1 _ 

Trim 

Manufacturer:  GM 

Color:  Red 

Figure  1 :  Physical  Schema  Variations 


-  Required  Human  Intervention:  Subject  Matter  Experts 
(SMEs)  will  always  have  to  be  consulted  when  examining 
heterogeneous  databases.  Figure  1  shows  multiple  terms  and 
physical  schemas  can  be  used  to  describe  the  same  object. 
SMEs  will  always  have  to  be  consulted  when  comparing  complex 
objects  to  make  the  final  determination  of  whether  the 
identified  common  data  elements  are  truly  common  and  whether 
the  associated  physical  schemas  are  common. 

The  problems  identified  above  mandated  that  the 
objectives  of  this  research  project  be  refined  to  include 
the  following: 

-  Need  for  a  method  that  can  simplify  the  search  and 
cotrparison  of  multiple  and  very  large  databases. 

The  method  must  provide  SMEs  the  information 
necessary  to  make  the  final  determination  of  what  is  common 
and  what  is  not  common.  This  reduces  work  by  showing  the 
SME  only  the  parts  that  are  likely  to  be  related. 
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D.  WHAT  IS  XML? 

This  research  has  been  carried  out  in  the  context  of 
the  markup  language,  XML.  But  what  is  a  markup  language? 
^^®borically ,  the  term  markup  originated  as  part  of  the 
document  piiblishing  process.  Documents  would  be  "marked  up" 
by  authors  and  editors  to  reflect  style  and  format 
instructions  for  the  printers  on  how  the  document  should  be 
Over  time  these  markup  comments  evolved  into 
markup  languages.  The  goal  of  these  markup  languages  was  to 
convey  specific  information  on  the  text  using  a  unique 
format  so  that  it  wouldn't  be  confused  with  the  text  itself. 

In  1969,  Ed  Mosher,  Ray  Lorie,  and  Charles  F.  Goldfarb 
of  IBM  Research  developed  the  Generalized  Markup  Language 
(GML)  [AndOO] .  GML  was  the  first  markup  language  developed 
to  support  modern  electronic  publishing  needs.  It  was  a 
meta-language  that  was  used  to  describe  other  languages, 
their  grammars,  and  vocabularies. 

GML  eventually  became  the  Standardized  Generalized 
Markup  Language  (SGML) .  in  1986,  SGML  was  adopted  as  an 
international  data  storage  and  exchange  standard  by  the 
International  Organization  for  Standardization  (ISO) 
designated  IS08879. 

SGML's  goal  was  to  define  descriptions  of  the  structure 
and  content  of  different  types  of  electronic  documents.  The 
with  SGML  is  that  it  is  extremely  complicated  and 
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was  only  used  by  those  who  do  large  amounts  of  publishing 
like  newspaper  companies  and  the  piiblishers  of  technical 
information.  This  complexity  has  increased  over  many  years 
as  more  and  more  is  added  to  the  specification  to  support 
evolving  publishing  requirements.  This  growing  complexity 
has  limited  SGML  use  to  those  companies/  organizations  that 
could  absorb  the  high  cost  of  implementing  and  maintaining 
SGML  proficiency. 

With  the  advent  of  the  internet /web.  Hypertext  Markup 
Language  (HTML)  was  developed  from  SGML  as  an  easily 
understandable  markup  language.  The  primary  objective  for 
HTML  was  that  it  had  to  be  a  simple  markup  language  that  a 
user  could  use  to  describe  a  document  structure  as  well  as 
the  role  each  part  played,  regardless  of  how  it  looked  on 
the  monitor.  The  benefit  of  using  HTML  is  that  it  is  easy 
to  learn,  it  is  supported  by  the  two  primary  browsers 
(Explorer  and  Netscape),  and  most  of  all  it's  cheap.  This 
last  benefit  is  the  primary  reason  for  the  explosion  of 
HTML ' s  use :  Anybody  can  use  HTML . 

A  problem  with  HTML  is  that  it  doesn't  provide  the 
ability  to  easily  modify  the  size/ structure  of  the  document 
to  the  size  of  the  screen.  As  described  earlier,  that  is 
one  of  primary  purposes  for  a  markup  language  is  to  provide 
structure  to  a  document  for  publishing.  In  HTML's  case, 
it's  the  publishing  of  information  on  the  web  to  any 
platform  that  can  display  web  pages.  For  standard  personal 
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computers,  the  display  of  this  information  is  done  extremely 
well.  But  HTML  has  a  more  difficult  time  displaying  that 
information  on  mobile  electronic  devices  like  Palm  Pilots, 
pagers,  and  cell  phones  that  are  interfaced  with  the 
internet . 

Another  problem  with  HTML  is  that  it  locks  the  data 
with  the  presentation  format.  Once  the  data  is  built  into 
an  HTML  page,  it  is  no  longer  easily  accessible  to  the  user 
and  cannot  easily  be  displayed  in  a  different  format  or  be 
processed  further  by  other  programs. 

These  two  problems,  along  with  many  others,  were  why 
XML  was  developed  and  why  it  has  rapidly  gained  in 
popularity. 

In  1996,  the  World  Wide  Web  Consortium  (W3C)  began  to 
develop  an  extensible  markup  language  that  would  combine  the 
flexibility  and  power  of  SGML  with  the  acceptance  of  HTML 
[AndOO]  .  This  was  the  start  of  the  Extensible  Markup 
Language  (XML) . 

As  the  starting  point  for  XML's  creation,  W3C  defined 
10  design  goals  [XMLRl.O]: 

1 .  XML  shall  be  straightforwardly  usable  over  the 
internet . 

2.  XML  shall  support  a  wide  variety  of  applications. 

3.  XML  shall  be  compatible  with  SGML. 
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4 .  It  shall  be  easy  to  write  programs  which  process 
XML  documents . 

5.  The  number  of  optional  features  in  XML  is  to  be 
kept  to  the  absolute  minimum,  ideally  zero. 

6.  XML  documents  should  be  human-legible  and 
reasonably  clear. 

7.  The  XML  design  should  be  prepared  quickly. 

8.  The  design  of  XML  shall  be  formal  and  concise. 

9.  XML  documents  shall  be  easy  to  create. 

10.  Terseness  in  XML  markup  is  of  minimal  importance. 

But  what  is  XML?  Simply  put,  XML  is  an  open  family  of 
markup  language  with  which  you  can  design  ways  of  describing 
data,  usually  for  storage,  transmission,  or  processing  by  a 
program.  XML  is  a  meta- language  for  describing  markup 
languages  thus  providing  the  facility  for  a  person  to 
define,  or  extend,  his/her  own  descriptive  terms  for  the 
data  and  the  structural  relationships  between  the 
descriptive  terms.  This  is  what  the  word  "Extensible"  in 
Extensible  Markup  Language  means  and  is  the  foundation  of 
XML.  The  following  describes  XML  functionality: 

-  XML  is  extensible:  An  XML  document  can  be  easily 
developed  and  understood.  Data  elements  and  attributes  are 
defined  to  personalize  the  XML  document  to  meet  any  specific 
requirement (s) . 
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-  XML  relates  well  to  relational  databases:  XML  creates 
and  maintains  a  hierarchical  data  structure.  Relational 
database  systems  use  relational  models  to  associate  data 
entities/tables  to  simplify  data  sorting,  searching,  and 
retrieval .  Although  these  two  data  structure  approaches  are 
very  different,  they  both  provide  the  means  to  create 
hierarchical  structures  that  can  be  maintained  and  shared. 

-  XML  is  not  tied  to  any  particular  context:  There  is 
no  requirement  for  any  particular  programming  languages, 
operating  system,  or  computer  platform  to  build  and  process 
XML  documents.  All  computer  platforms  have  sirrple  text 
editors  that  can  be  used  to  develop  XML  documents , 

-  XML  is  self -describing:  An  XML  document  should  be 
easy  to  read.  This  understandability  results  from  the 
Process  of  defining  the  data  elements  and  related  hierarchy 
based  on  the  designer's  own  "common  sense"  perspective  of 
the  data. 

XML  provides  opportunity  for  development  of 
standardized  data  representations:  The  transfer  of  data 
between  different  database  systems  developed  by  different 
manufacturers  using  different  operating  systems  has  been  a 
complicated  process.  XML  has  the  ability  to  support 
development  of  independent  data  formats  that  multiple 
database  systems  can  understand. 
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E.  SCOPE  OF  RESEARCH: 

The  Joint  Battle  Center  (JBC)  and  the  Naval 
Postgraduate  School  (NPS)  defined  the  scope  of  this 
research.  The  Joint  Battle  Management  Initiative  Assessment 
Plan  [JBMIOO]  describes  the  NPS  led  XML  Schema  Investigation 
research  to  execute  the  following: 

Determine  methods  for  assuring  scalability  of 
solution  to  legacy  and  migration  C4I.  This  requires  a 
method (s)  that  can  support  analysis  and  comparisons  of  both 
legacy  and  evolving  common  databases  like  JCDB. 

-  Determine  what  parts  of  a  legacy  system  view  could  be 
materialized  from  previous  shared  schemas.  This  requires 
the  identified  method (s)  to  be  able  to  identify  common 
elements  and  physical  schemas. 

-  Determine  how  to  materialize  those  parts  relevant  to 
such  an  assessment.  This  requires  the  identified  common 
data  elements  and  schemas  be  integrated  into  a  global  common 
schema . 

This  thesis  describes  the  research  associated  with  the 
examination  of  previously  developed  analysis  methods  that 
support  different  aspects  of  the  defined  tasks.  Then  a  new 
and  original  XML-based  database  analysis  and  cottparison 
method,  developed  as  part  of  the  research  effort,  is 
described  in  detail .  This  method  is  demonstrated  to  show 
how  it  supports  the  described  JBC/NPS  tasks. 
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P.  LIMITATIONS  IMPACTING  RESEARCH; 

The  original  research  objectives  (described  earlier) 
for  this  thesis  effort  involved  detailed  comparisons  of  the 
JCDB,  AFATDS,  MIDB,  and  GCCS  Track  Database  Manager  Database 
(TDBM)  .  As  directed  by  NPS,  the  particular  task  to  be 
investigated  in  this  research  effort  focused  on  the  analysis 
of  the  JCDB  and  AFATDS  databases . 

Unfortunately,  the  AFATDS  database  dictionary  and 
entity  relationship  diagrams  proved  to  be  unattainable  in 
sufficient  time  to  support  this  research  effort.  After 
several  months  of  effort  by  several  organizations  and 
individuals  (including  myself)  information  relating  to  the 
AFATDS  database  could  not  be  acquired.  The  AFATDS  database 
is  a  closely  held  document  that  would  not  be  released  to 
support  a  master's  level  research  project.  The 
unavailability  of  this  critical  component  forced  a 
modification  to  the  original  research  objectives  from  the 
examination  of  the  AFATDS  to  the  examination  of  the  MIDB. 
The  MIDB  Data  Dictionary  provided  sufficient  detail  to 
support  the  development  of  entity  relationship  diagrams  that 
represented  certain  views  of  the  MIDB.  The  developed  views 
of  the  MIDB  were  then  compared  against  JCDB  views  extracted 
from  the  provided  JCDB  Data  Dictionary  and  Entity 
Relationship  Diagrams. 
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The  sheer  size  of  JCDB  and  MIDB  presented  a  significant 
challenge  when  executing  an  analysis  of  the  two  databases. 
The  specific  database  application  software  was  required  to 
process  these  large  databases.  Since  the  application 
software  could  not  be  acquired  in  time  to  support  this 
research  effort,  smaller  views  of  particular  portions  of  the 
two  databases  were  chosen  for  examination. 

Another  limitation  faced  during  this  research  effort 
was  that  XML  is  still  evolving,  in  some  cases  evolving 
rapidly.  Some  of  the  necessary  recommendations  are  still  in 
draft  form.  It  is  expected  that  within  one  year  all 
necessary  XML  Recommendations  (to  be  discussed  later)  will 
be  finalized  and  approved.  It  will  then  take  the  commercial 
sector  time  to  develop  and  field  software  that  incorporates 
these  XML  based  capabilities.  However,  in  some  cases,  the 
commercial  sector  is  already  producing  software  that 
incorporates  capabilities  defined  in  the  draft 
recommendations.  When  required,  the  XML  based  analysis 
process  to  be  described  in  this  thesis  had  to  employ  XML 
based  capabilities  that  are  still  undergoing  review. 

G.  RESEARCH  ASSUMPTIONS 

Assumption  #1:  The  XML  related  draft  recommendations 
are  stable  and  will  be  finalized  in  virtually  the  same  form 
and  content . 
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Assumption  #2 :  Current  XML  commercial  sector 
developments  will  continue  at  the  same  rapid  pace  once  all 
XML  related  recommendations  are  finalized  and  approved. 


H .  ORGANI ZATION 

This  thesis  is  organized  into  the  following  chapters: 


•  Chapter  II  describes  the  databases  to  be  examined  in 
this  research  effort. 

•  Chapter  III  provides  a  review  of  previous  work  in 
this  area.  This  includes  descriptions  of  other 
applicable  examination  methods,  ongoing  Department 
of  Defense  XML  efforts,  and  a  rationalization  of  why 
a  new  XML  based  analysis  method  is  required. 

•  Chapter  IV  presents  the  XML  based  analysis  method 
developed  during  this  research  effort.  The  overall 
analysis  process  is  described.  An  execution  of  the 
developed  method  with  an  analysis  and  comparison  of 
JCDB  and  MIDB  views  will  follow  the  method 
description. 

•  Chapter  V  presents  the  conclusions  and 
recommendations  of  future  work  derived  from  this 
research  effort. 

•  Following  Chapter  V  are  several  appendices 
containing  the  materials  used  to  support  this 
research  effort.  Also  included  is  the  code 
developed  that  executes  this  XML  based  analysis. 

The  appendices  also  contain  the  thesis  glossary  and 
references  used  in  this  research  effort. 
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II.  DATA  AMD  PHYSICAL  SCHEMA  OF  DATABASES 


The  two  databases  to  be  analyzed  in  this  research 
effort  are  the  JCDB  and  MIDB.  Both  are  considered  high 
level  common  databases  that  incorporate  data  from  several 
systems  for  use  by  commanders  who  require  information  from 
many  sources  to  execute  battle  management . 

A.  JOINT  COMMON  DATABASE 

The  JCDB  is  a  key  component  of  the  U.S.  Army's  efforts 
to  employ  common  software  and  data  across  command  and 
control  (C2)  systems  [JCDB99] .  The  JCDB  resides  on  the  Army 
Battlefield  Command  System  (ABCS)  and  provides  the  data 
necessary  to  support  the  common  applications  that  build  the 
Common  Tactical  Picture  (CTP) .  Some  of  the  information 
displayed  as  part  of  the  CTP  is : 

•  Friendly  and  enemy  locations,  activities,  strength, 
status,  estimated  and  current  capability. 

•  Tracking  of  resources . 

•  Tracking  of  materiel  locations,  status,  and 
quantities. 

•  Mapping  of  ground  and  air  control  measures. 

•  Mapping  of  facilities. 

•  Target  nomination,  engagement,  and  damage 
assessment . 
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•  Evaluation  and  verification  of  reported  information. 

•  Development  of  operational  orders  and  operational 
plans. 

B.  JCDB  PRODUCTS 

The  JCDB  products  available  to  support  this  research 
effort  were  the  Joint  Data  Model  and  the  JDD.  The  Joint 
Data  Model  is  a  logical  data  model  that  displays  the  entity 
relationships  of  the  JCDB  entities  and  attributes.  The  JDD 
is  a  data  dictionary  that  provides  data  entity  names, 
definitions,  datatype  and  domain  values /enumerated  types  for 
the  entities. 

C.  MODERNIZED  INTEGRATED  DATABASE 

The  GCCS  13  system  objectives  are  to  provide  accurate, 
user  friendly,  and  immediately  accessible  Integrated  Imagery 
and  Intelligence  (13)  capabilities  to  support  the 
i9hter .  The  GCCS  13  provides  commanders  with 

situational  awareness  and  track  management  with  a  standard 
set  of  linked  tools  that  maximizes  commonality  across  the 
tactical,  theater,  and  national  communities  [I3BR] 

The  GCCS  13  provides  access  to  the  information 
maintained  in  the  MIDB.  This  infoimiation  includes: 

•  National  and  Theater-level  intelligence  on 
facilities. 

•  Order-of-Battle 
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•  Information  on  equipment  and  targets  (including 
target  assessments) 

•  Derived  intelligence  entered  by  tactical 
intelligence  assets 

This  information  is  used  to  provide  operational 
commanders  and  intelligence  analysts  quick  access  to 
intelligence  and  imagery  through  the  Common  Operational 
Picture  (COP) . 

D.  MIDB  PRODUCTS 

The  only  MIDB  product  available  to  support  this 
research  effort  was  the  Modernized  Integrated  Database- 
Database  Design  Document  (MIDBD3) .  The  MIDBD3  is  a  data 
dictionary  that  provides  data  entity  names,  definitions, 
datatype  and  domain  values/ enumerated  types  for  the 
entities . 
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III.  SURVEY  AND  ASSESSMENT  OP  PREVIOUS  WORK 


A.  BACKGROUND 

With  the  focus  of  this  research  effort  to  locate  and 
analyze  commonality  between  heterogeneous  databases  it  is 
important  to  understand  the  components  that  will  make  up  the 
identification  process.  The  databases  types,  XML-database 
relationships,  and  XML- information  sharing  need  to  be 
understood  before  delving  into  an  evaluation  of  previous 
methods . 

B .  DATABASES 

There  are  two  types  of  database  management  systems 
available  to  represent  data.  They  are  the  Object  Oriented 
Database  Management  System  (OODBMS)  and  the  Relational 
Database  Management  System  (RDBMS) .  Each  provides 
capabilities  that  support  unique  database  storage  and 
manipulation  capabilities.  Object  Oriented  Database 
Management  Systems  provide  the  capability  to  deal  with 
objects  that  have  complex  relationships  and  depth  [ANDOO] . 
Relational  Database  Management  Systems  provide  the 
capability  to  model  many  real  world  problems  and  provide 
more  thorough  and  rapid  manipulation  of  the  data  [ANDOO] . 
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1. 


OODBMS 


OODBMSs  provide  the  capability  to  build  objects  and 
relate  those  objects  to  other  objects.  A  complex  object 
interrelationship  can  quickly  develop  when  the  database 
contains  several  levels  of  objects.  The  OODBMS  provides  the 
capability  to  build  these  complex  databases  and  to 
manipulate  them.  This  manipulation  includes  the  ability  to 
add,  delete,  and  modify  nodes  anywhere  in  the  object- 
oriented  database  (OODB)  without  impacting  the  rest  of  the 
database.  OODBMSs  also  provide  the  standard  set  of 
facilities  to  search  and  retrieve  data  from  the  database. 

2 .  RDBMS 

RDBMSs  use  tables  comprised  of  rows  and  columns  to 
store  and  relate  data .  The  row  and  column  headings  provide 
the  means  to  define  the  data.  The  simple  example  of  a  RDBMS 
shown  in  Figure  2  provides  information  on  cars.  The  tables 


Cars  Owned 


Make 

Model 

Type 

1 

Chevy 

mm 

I— 

5 

2 

GMC 

■ 

BH 

Sport 

tm 

SUV 

Red 

6 

Blue 

Figure  2:  Simple  Relational  Database 
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provide  a  simple  representation  of  two  cars.  The  top-level 
"Cars  Owned"  table  provides  overall  data  relating  to  the 
cars.  The  "Type"  and  "Color"  Tables  are  joined  to  the  Cars 
Owned  Table.  This  joining  mechanism  defines  how  the 
different  tables  are  related.  A  relational  database  is 
built  through  these  relationships  between  multiple  tables. 

3.  RDBMS/OODBMS  Advantages  and  Disadvantages 

It  is  the  RDBMS's  efficiency,  simplicity,  and  ability 
to  support  most  database  storage  and  manipulation  problems 
that  makes  it  more  popular  and  more  widely  used  than 
OODBMSs.  This  stems  from  the  fact  that  RDBMSs  have  been  in 
existence  longer  and  are  more  mature  than  OODBSs.  The 
primary  disadvantage  with  RDBMSs  is  that  when  modeling 
extremely  complex  relationships  the  RDBMS's  efficiency  can 
be  affected.  OODBMSs  can  better  represent  these  complex 
database  relationships. 

C.  XML  AMD  DATABASES 

Previous  sections  of  this  thesis  describe  XML  and 
databases.  This  section  will  describe  the  similarities  and 
differences  between  XML  and  databases.  In  most  cases  though 
XML  and  databases  (and  related  DBMSs)  do  provide  similar  ‘ 
data  search  and  manipulation  capabilities,  it's  just  the 
extent  to  which  they  employ  those  capabilities  that  defines 
their  similarities  and  differences.  In  general, 

descriptions  of  database  technologies  apply  to  both  RDBMSs 
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and  OODBMSs.  If  the  description  specifically  relates  to  one 
or  the  other,  it  is  specifically  identified. 

1.  Similarities 

Both  XML  and  database  technologies  maintain  data  in 
hierarchical,  parent/child  relationships.  XML  and  OODBMSs 
can  maintain  extremely  complex,  very  deep  relationships.  As 
discussed  earlier,  RDBMSs  do  not  efficiently  process  these 
complex  relationships  as  well. 

XML  and  database  technologies  provide  the  ability  to 
search  and  manipulate  data.  Since  the  DBMSs  provide  this 
capability  through  their  unique  internal  schemas  and  query 
languages  they  are  very  efficient  in  their  execution.  XML 
provides  the  designer/ developer  a  great  amount  of 
flexibility  in  the  design  of  their  documents  through  the  use 
of  internal  or  external  Document  Type  Definitions  (DTDs)  or 
Schemas,  namespace  definitions,  etc.  The  XML  document  can 
be  just  about  any  size  and  can  retain  an  unknown  level  of 
complexity.  To  cope  with  this  flexibility  of  design,  XML 
ettploys  open-ended  languages  and  Application  Programming 
Interfaces  (APIs)  like  XQuery,  XPointer,  XLink,  and  Document 
Object  Model  (DOM)  APIs  to  support  this  flexibility  of 
design.  Certain  speed  of  service  inefficiencies  result  from 
having  to  account  for  these  open  designs. 
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2. 


Differences 


As  described  earlier,  DBMSs  provide  a  database 
manipulation  efficiency  that  is  not  found  in  XML.  The 
DBMS ' s  efficiency  stems  from  their  strict  definition  of  data 
structure  and  the  data  search  and  manipulation  capabilities 
specifically  tailored  to  that  data  structure.  These 
efficiencies  of  DBMSs  and  XML  inefficiencies  reflect  the 
fact  that  XML  is  not  a  DBMS . 

XML  provides  a  single  structured  view  of  the  data  as 
defined  by  the  DTD  or  XML  Schema.  Rearranging  of  the  data 
will  require  a  corresponding  modification  to  the  DTD  or  XML 
Schema.  DBMSs  retain  the  capabilities  to  easily  modify  the 
stiructure  of  the  database. 

The  XML  document  is  basically  a  text -formatted  document 
that  is  independent  of  any  particular  platform  or  software 
application.  DBMSs  store  their  databases  in  DBMS  specific 
formats.  The  DBMSs  must  be  operated  from  very  specific 
computing  platforms  with  specific  software  applications. 

XML  is  not  restricted  by  any  document  structure.  It 
can  reflect  any  structure  the  designer  desires.  Databases 
developed  in  DBMSs  must  adhere  to  specific  database 
structures . 

3 .  Conclusion 

This  XML  -  database  comparison  demonstrates  that  though 
there  are  differences  between  the  two,  the  common  thread 
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between  them  is  the  data.  Each  maintains  and  manipulates 
the  data  in  their  own  way.  Recognizing  the  value  of  XML, 
most  DBMS  manufacturers  are  beginning  to  integrate  XML 
resources  and  capabilities  into  their  software.  These  XML 
resources  and  capabilities  will  be  described  in  detail  in 
the  following  section.  An  example  of  one  XML  capability 
being  integrated  is  an  XML  translator  that  supports  the 
translation  from  a  specific  database  format  into  an  XML 
document.  This  allows  the  DBMS  to  take  advantage  of  web 
based  functionality  associated  with  XML. 

D.  COMMERCIAL  DATABASE  XML  EFFORTS 

The  primary  advantage  for  DBMS  manufacturers  for 
integrating  XML  capabilities  into  their  products  is  to 
support  web  transmission  and  manipulation  of  their 
databases .  Another  advantage  is  that  the  use  of  XML 
simplifies  inter-database  transmission.  In  the  past, 
communications  between  different  brands  of  database  products 
required  the  development  of  complex  translators.  These 
translators  translate  the  database  from  one  database  format 
to  another.  While  this  solution  worked,  it  also  required 
the  translator  to  undergo  costly  rebuilds  each  time  one  or 
the  other  DBMSs  changed.  XML  provides  the  means  to  support 
translation  from  one  database  format  to  XML  and  then  from 
XML  to  another  database  format. 
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other  XML  capabilities  being  integrated  include  XML 
parsers,  XML  storage,  and  XML  document  queries.  This  thesis 
will  briefly  examine  the  XML  capabilities  being  integrated 
into  the  Oracle,  Sybase,  and  Informix  DBMSs.  The  XML 
related  information  presented  comes  from  each  of  the 
manufacturers  web  sites. 

1 .  Oracle 

Of  all  the  DBMS  manufacturers,  it  appears  Oracle  is 
investing  in  XML  the  heaviest.  They  have  developed  the 
Oracle  Internet  Platform  that  provides  integrated  support  of 
internet  standards,  including  XML  and  JAVA  [ORCWS] .  Oracle 
8i  contains  a  built-in  JAVA  Virtual  Machine  that  can  execute 
Oracle ' s  XML  based  components . 


Oracle ' s 

interMedia  Text  can 

be 

used 

to 

perform 

searches  on 

XML  documents  stored 

in 

Oracle 

8i 

The 

foundation  for  these  searches  are  simple  textual  matching 
algorithms  that  can  be  used  on  an  individual  XML  document  or 
on  the  entire  database  that  contains  the  documents. 

Oracle  provides  the  capability  to  store  the  XML 
document  in  its  original  XML  structure.  This  capability  is 
advantageous  if  the  document  does  not  have  to  be  updated 
often  or  if  it  has  to  be  transmitted  as  a  whole.  Otherwise, 
Oracle  provides  the  capability  to  store  the  XML  document  as 
data  in  the  Oracle  database  format.  This  storage 
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alternative  is  beneficial  if  the  XML  document  is  undergoing 
a  significant  amount  of  updates  to  the  data. 

Oracle  stores  the  XML  document  in  its  database  format 
by  capturing  the  attributes  of  the  data  elements  in  a 
relational  table  and  the  objects  are  defined  to  convey  the 
XML  document  structure.  The  XML  Structured  Query  Language 
(SQL)  utility  provides  the  means  to  store  and  retrieve  the 
document  from  the  database.  Once  stored  in  the  database, 
the  data  can  be  updated,  queried,  rearranged,  reformatted, 
and  extracted  as  required. 

Oracle  Views  can  be  used  to  store  an  object  "on  the 
fly"  by  combining  XML  data  stored  in  many  ways .  In  effect 
the  XML  document  is  stored  twice  in  Oracle  with  each  linked 
to  the  other.  This  approach  provides  the  ability  to  access 
the  entire  document  along  with  the  data  in  the  objects 
defined  in  the  database.  The  XML  SQL  provides  the  ability 
to  extract  the  assembled  data  as  a  single  XML  document. 

Oracle  provides  several  XML  parsers  to  support  JAVA,  C, 
C++,  and  PL/SQL  applications.  The  parsers  also  provide 
support  to  the  Document  Object  Model,  Simple  API  for  XML 
(SAX)  interfaces,  XML  Namespaces,  and  Extensible  Stylesheet 
Language  Transformation  (XSLT) .  All  of  these  parsers 
provide  XML  document -validating  capabilities. 

Oracle  utilizes  XML  to  support  exchange  of  data  between 
business  applications.  Oracle  exploits  the  DTDs  in  the  XML 
documents  to  identify  the  common  data  elements  and  structure 
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to  support  sharing  of  the  data.  To  share  data  from  one  XML 
document  to  another,  the  structure  and  content  of  the  data 
being  shared  has  to  compare  favorably  between  the  two  XML 
DTDs.  If  the  DTDs  do  not  share  common  data  elements  or 
structure,  the  necessary  portions  of  one  or  both  of  the 
documents  are  transformed  using  XSLT  into  a  common  format 
thus  allowing  one  document  to  share  data  with  the  other. 

In  the  future,  Oracle  plans  on  expanding  its  XML 
querying  capabilities  to  enable  not  only  identification  of 
the  individual  data  elements  but  also  the  logical  view 
related  to  that  data  element .  This  will  provide  the 
capability  to  search  for  specific  data  elements  and/or 
specific  XML  document  structure. 

2 .  Sybase 

Sybase ' s  Adaptive  Server  Enterprise  12 . 0  provides  the 
ability  to  create,  store,  retrieve,  and  query  XML  documents. 
Based  on  the  information  provided  in  the  Sybase  web  site 
[SYBWS] ,  Sybase  provides  an  XML  parser  to  ensure  all  XML 
documents  developed  are  valid.  Once  deemed  valid,  Sybase 
provides  the  capability  to  store  XML  documents  in  relational 
tables.  The  entire  XML  document  can  be  stored  as  a  whole  or 
as  native  text  in  text  or  image  columns.  Any  XML 
transactions  can  be  mapped  into  new  or  existing  relational 
tables .  Sybase  provides  integrated  textual  search 
capabilities  to  query  the  document  and  to  create  XML 
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formatted  query  results  for  incorporation  into  XML 
documents . 

The  JAVA  capabilities,  provided  by  Sybase's  Seirver 
Enterprise  12.0,  can  be  used  to  incorporate  any  commercially 
available  JAVA-based  XML  tools. 

The  capabilities  provided  by  Sybase  are  comparable  to 
those  provided  in  Oracle.  Perhaps  the  one  advantage  Oracle 
has  over  Sybase  is  that  their  products  are  more  widely  used 
in  the  commercial  sector. 

3 .  Informix 

Informix  intends  on  exploiting  XML  to  support  data 
sharing.  The  initiative  that  supports  this  ability  is  the 
Informix  Internet  Foundation  2000.  This  foundation  consists 
of  their  Informix  Dynamic  Server  2000  and  a  series  of  tools 
to  support  Internet  applications.  The  Informix  Web 
Datablade  Module  is  the  first  of  the  modules  that  has  been 
created  to  support  exploitation  of  XML  [INFWS] . 

Informix  provides  the  ability  to  create,  store,  and 
query  XML  documents  in  their  database.  It  also  supports  the 
integration  of  XML  documents  with  legacy  data  in  the 
database . 

4 .  Summary 

Each  of  the  DBMS  described  above  provides  the  ability 
to  store,  search,  manipulate,  and  extract  XML  documents  from 
their  databases.  This  ability  to  extract  XML  documents  from 
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databases  significantly  simplifies  the  process  to  execute 
the  XML  based  analysis  method  that  will  be  described  in 
subsequent  sections. 

E.  DEPARTMENT  OF  DEFENSE  AND  XML 

As  with  the  commercial  sector,  the  Department  of 
Defense  (DoD)  has  recognized  the  value  of  XML  to  aid  in  the 
interoperability  between  dissimilar  systems.  They  also 
recognized  the  danger  of  several  DoD  organizations  possibly 
developing  their  own  unique  XML  representations  that  could 
hinder  interoperability.  As  a  result,  the  DoD  has  begun  a 
concerted  effort  to  intelligently  control  XML  development 
and  implementation  as  it  relates  to  interoperability.  One 
means  of  control  is  the  use  of  a  DoD-wide  XML  Namespace 
Registry  to  categorize  and  maintain  common  and  reusable  XML 
elements . 

Draft  guidance  entitled  "Guidance  on  the  Use  of 
Extensible  Markup  Language  within  DoD"  [DISAOO]  was  released 
on  29  Aug  00.  The  primary  guidance  states  that  the  DoD  will 
implement  a  common  DoD  registry  of  namespaces.  All 
developers  of  XML  documents  will  be  required  to  review  this 
repository  for  reusable  tags,  elements,  and  constructs 
before  developing  new  ones.  If  new  tags,  elements,  or 
constructs  are  developed  it  should  be  determined  if  they  are 
reusable.  If  so,  the  developer  should  submit  the  reusable 
components  to  the  registry. 
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1.  What  is  a  Namespace? 

Namespaces  are  used  in  XML  to  ensure  uniqueness  of  the 
XML  elements.  This  ability  to  define  uniqueness  is 
important  in  XML  since  it  is  this  uniqueness  that  will  allow 
one  element  to  be  distinguished  from  another.  The 
extensibility  of  XML  allows  the  XML  document  developer  to 
create  any  element  desired.  Problems  can  arise  when  an 
element  could  be  interpreted  in  multiple  ways.  The 
following  two  examples  demonstrate  this  problem: 


Example  A:  Compare  the  following  two  XML  documents 
adapted  from  example  in  [BOUROO] : 

<?XML  Version="l. 0"?> 

< Address > 

<Street>ll  Mile</Street> 

<City>Warren</City> 

<State>Michigan</State> 

<Zip>48397</Zip> 

</Address> 

and 

<?XML  Version="l . 0"?> 

<PersonalID> 

<  Addr  e  s  s  >XXX@f  ake  -  ema  i  1 .  com<  /  Addr  e  s  s  > 

</ Personal ID > 
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Example  B:  Also  compare  the  following  two  XML 
documents : 

<?XML  Version="1.0"?> 

<Tank> 

<Type >Heavy< / Type > 

<Nomenc lat ure  >M1 < /Nomenclature  > 

</Tank> 

and 

<?XML  Version="1.0"?> 

<Tank> 

<Type>Water</Type> 

<Capacity>500  USGal</Capacity> 

</Tank> 

One  of  the  greatest  advantages  in  using  XML  is  that  it 
,  allows  the  XML  developer  to  develop  the  XML  elements  that 
best  suits  their  needs.  This  extensibility  also  can  cause 
problems.  The  two  previous  examples  show  how  like  terms  can 
define  very  different  things.  This  is  why  namespaces  are 
required. 

But  what  is  a  namespace?  "XML  namespaces  are 
collections  of  names,  nothing  more" [BOUROO] .  Namespaces 
provide  the  ability  to  develop  unique  identifiers  for  XML 
elements.  This  can  be  demonstrated  by  reexamining  the 
previous  examples  that  now  incorporate  namespaces: 

Example  C:  Adapted  from  example  in  [BOUROO] : 
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<addr : Address 

xmlns : addr= "http ; // www . ?  ?? . com/ addresses " > 

<addr : Street>ll  Mile</addr : Street > 

<addr ; City>Warren< /addr : City> 

<addr : State>Michigan</addr : State> 

<addr :Zip>48397</addr :Zip> 

< / addr : Addre  s  s  > 
and 

<se2rv:  Personal  ID 

xmlns;serv= "http://www. *** .com/emailaddresses"> 

<serv:Address>XXX@fake- 
email .  com</ se2rv:Address> 

</ serv: Personal ID> 

Example  D:  Also  compare  that  following  two  XML 
documents : 

<ArmyVehicle : Tank 

xmlns : ArmyVehicle="http : //www. $$$ . com/vehicles " > 

<ArmyVehicle :  Type>Heavy</ArmyVehicle :  Type> 

<ArmyVehicle :Nomenclature>Ml 
</ArmyVehicle :Nomenclature> 

</ArmyVehicle : Tank> 

and 

<Storage :Tank  xmlns 

Storage= "http : //www . @@® . com/Storage " > 

<Storage : Type>Water</Storage : Type> 

<Storage :Capacity>500 
USGal</Storage :Capacity> 

</ Storage : Tank> 


32 


The  rationale  for  using  namespaces  is  that  it  allows  an 
XML  developer  to  freely  distribute  their  XML  documents  to 
others  since  the  potential  XML  element  conflicts  will  be 
eliminated.  The  use  of  namespaces  simplifies  the  process  of 
using  XML  to  communicate  data  and  in  the  case  of  the  DoD,  to 
support  interoperability  since  each  element  will  be  unique 
and  understandable  per  the  namespace  definition. 

In  Examples  C  and  D  the  Unified  Resource  Identifier 
(URI)  (shown  in  bold  below)  identifies  the  namespaces: 

<addr: Address  xmlns :addr= "http: //www. ??? .ccm/ addresses "> 

URIs  are  used  because  they  are  a  well-known  system  for 
creating  unique  identifiers  [BOUROO] .  These  URIs  are 
maintained  by  a  singular  owner/organization  that  has  the 
responsibility  of  defining  the  namespace  common  elements. 

Recognizing  the  need  for  namespace  ownership,  the  DoD 
XML  Guidance  [DISAOO]  states  the  following:  "Once  approved, 
the  namespace  manager  will  exercise  aggressive  oversight  of 
his  namespace."  and  "...the  namespace  manager 
will .. .establish  a  registry  and  repository  (R&R)  of 
namespace  specific  elements  and  constructs."  The  Namespace 
Registry  is  a  mechanism  through  which  the  relevant  elements 
and  constructs  can  be  registered  to  coincide  with  a  specific 
location  that  can  be  located  through  queries.  The  Namespace 
Repository  is  the  location  where  the  registry  resides  and 
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f2roTn  which  they  C3n  he  loceted  end  iretirieved.  The  top  level 
XML  Namespace  R&R  is  maintained  by  Defense  Information 
Systems  Agency  (DISA)  with  the  individual  owners /name space 
managers  responsible  for  their  own  particular  namespace. 

DISA's  overall  role  in  XML  namespace  management  is 
part  of  their  management  of  the  Defense  Information 
Infrastructure  Common  Operating  Environment  (DIICOE) .  The 
DIICOE  is  a  data  environment  defined  to  support 
• • -interoperability  and  software  reuse  in  a  secure, 
reliable,  and  global  networked  environment" [DISAWS] .  The 
DIICOE 's  data  service  infrastructure  employs  "sets  of  shared 
schemas,  data  management  and  services,  build- time  and 
runtime  tools,  server  development  and  operating  procedures, 
and  technical  guidance  for  supporting  COE-based  mission 
3-Pplications "  ,  The  goal  for  the  DII  is  to  migrate  from  many 
dissimilar  data  stores  to  a  set  of  standardized  COE 
compliant  data  seirvices. 

DISA  is  using  SHAred  Data  Engineering  (SHADE)  as  the 
DIICOE  data  emporium  that  maintains  these  COE  compliant  data 
ssrvices .  Contained  within  the  SHADE  is  the  XML  Namespace 
Registry. 

2 .  DXICOE  Namespace  Registsry 

DISA's  Namespace  Registry  standardizes  a  set  of 
elements  developed,  coordinated,  and  approved  in  the  COE 
community.  The  registry  provides  the  user  the  ability  to 
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search  and  retrieve  these  common  elements. 


If  a  desired 


element  (or  set  of  elements/constructs)  cannot  be  located, 
the  user  can  submit  a  proposed  element  (or  set  of 
elements/constructs)  to  the  "Community  of  Interest"  (COI) 
[DISAOO]  for  consideration  of  incorporation  into  the  XML 
Registry.  Currently  there  are  11  COI's: 


COI 

Owner 

COE  Enterprise 

DISA-DIICOE  Chief  Engineer 

Ground  Operations 

Army- PM  for  JCDB 

General  Military 

Intelligence 

Defense  intelligence  Agency 

Aerospace  Operations 

USAF-AF  Common  Data 

Environment  Staff 

Messages 

DISA- Chair  USMTF  CCB 

Track  and  Reports 

Navy- Common  Track  Data  Store  Engineer 

Geospatial  &  Imagery 

NIMA-NIMA  Engineer 

METOC 

Navy -Developer  of  Meteorological  and 

Oceanographic  Models 

Combat  Support 

DISA-CCSS  Engineer 

Finance 

DFAS 

Personnel 

DIMHRS 

One  of  the  XML  COIs  identified  above  is  the  Message 
COI.  This  COI  primarily  focuses  on  the  namespaces 
identified  to  support  ongoing  XML-MTF  effort  led  by  the  Air 
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•  The  COI  provides  a  means  to  facilitate  determination 
of  tag  names  for  the  corresponding  XML  translations  of  the 
JCDB. 

3 .  XML-MTP 

The  single  largest  XML  effort  ongoing  in  the  DoD  is  the 
XML-United  States  Message  Text  Format  (USMTF)  initiative. 
This  effort  focuses  on  the  capability  to  build  XML 
translations  of  USMTF  messages  and  USMTF  translations  of  XML 
documents .  USMTF  is  one  of  the  message  formats  used  to 
convey  data  to  the  JCDB  and  MIDB. 

USMTF  is  a  text  (character)  oriented  message  format 
used  to  support  tactical  and  support  communications. 
Currently  there  are  over  350  different  message  types  used. 
A  primary  objective  for  the  USMTF  program  is  to  support  the 
production  of  messages  that  can  be  read  by  humans  and 
machines.  In  effect,  USMTF  is  an  artificial  language  that 
employs  a  controlled  vocabulary.  This  vocabulary  allows  the 
user  to  develop  messages  that  can  be  understood  by  both 
humans  and  machines.  This  understandability  is  important 
since  the  USMTF  messages  are  used  for  inter-service  and  with 
9-llisd.  communications.  The  vocabulary  is  comprised  of  words 
arranged  in  predetermined  formats  that  convey  specific 
information  based  on  the  location  of  the  words  and  their 
meaning . 
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The  syntax  of  the  USMTF  message  defines  how  it  is 


structured.  The  basic  structure  is  comprised  of  message, 
sets,  and  fields.  The  natural  language  equivalents  are 


words , 

sentences. 

and 

text . 

The 

vocabulary. 

of  an 

MTF 

message 

consists 

of 

formats 

for 

the 

fields. 

sets. 

and 

message 

The 

terms 

that 

complete 

these 

fields 

are 

represented  by  field  contents,  set  format  identifiers,  and 


message  test  identifiers. 

The  structure,  semantics,  and  syntax  are  defined  in 
MIL-STD-6040 .  It  is  this  standard  that  defines  the  USMTF 
schema.  The  following  example  displays  how  USMTF  messages 
can  be  structured.  The  following  example  shows  a  USMTF 
columnar  structured  messages  [AMP99] : 


UNCLAS 

EXER/OLIVE  DRAB  99// 

MSGID/SITREP/AFOP-JT// 

REF/A/ORDER/CTG122 .4/161500ZJAN1999/0101006// 

PERID/172000Z/TO:181800Z/ASOF:171800Z// 

MAP/1501/11/1/6-GSFS// 

HEADING/ ENEMY/ / 

AMPN/LIGHT  RESISTANCE,  ENEMY  CASUALTIES  UNKNOWN// 

5EUNIT 

/DE/CY/ACTTYP/ENUNIT  /UNITLOC  /TIMPOS 

/Ol/RS/DEPLOY/345  MTR  RFL  DIV/RIDGELINE  CHARLIE  /171200Z// 
HEADING/OWN  SITUATION// 

BNDLINE/FEBA/50QRD99109920/50QRD99309940/50QRD99509960/50QRD 

99809908// 

BT 

#0009 
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4. 


Problems  with  USMTF 


A  major  problem  with  USMTF  messages  is  that  they  can 
not  be  uniformly  exchanged  between  all  C4I  systems.  There 
are  several  C4I  systems  fielded  that  don't  use  USMTF  as  the 
means  to  communicate.  ,  A  common  COTS  based  method  of 
representing  messages  would  improve  interoperability  between 
C4I  systems. 

A  second  problem  is  that  USMTF  is  a  government  managed 
standard  that  has  been  in  use  for  many  years  by  all  services 
and  many  allied  commands.  The  USMTF  related  software  has  to 
be  developed,  fielded,  and  maintained  at  significant  cost  to 
the  government.  It  was  realized  that  there  could  be 
advantages  in  pursuing  commercial -off-the-shelf  (COTS)  based 
alternatives  for  USMTF.  Cost  savings  could  be  realized  from 
adopting  a  COTS  based  alternative  since  a  wider  variety  of 
systems  might  be  able  to  recognize  a  COTS  based  version  of 
USMTF  messages . 

Another  problem  with  USMTF  messages  is  that  they  can 
not  be  easily  read  [HOP99]  .  As  can  be  seen  from  the  USMTF 
example  the  message  is  not  inherently  readable  unless  you 
have  a  detailed  understanding  of  the  USMTF  vocabulary. 

A  final  problem  is  that  USMTF  messages  can  not  be 
easily  prepared  and  are  subject  to  errors.  Extensive  use  of 
MIL-STD-6040  and  other  references  is  required  to  prepare  the 
messages . 
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5.  XML-nSMTF  Mapping 

In  1998,  Mitre  Corporation  working  for  the  Air  Force 
began  to  investigate  if  XML  could  be  ertployed  to  deal  with 
the  USMTF  problems  described  previously.  It  was  determined 
that  XML  could  provide  an  alternative  method  to  represent 
USMTF  data  and  structure.  It  was  also  accompanied  by  other 
COTS/XML  based  resources/capabilities  (like  XSLT)  that 
supported  transformation  of  that  data.  The  alternative, 
called  "XML-MTF"  provides  several  benefits  [HOP99] : 

-  XML-MTF  provides  improved  flexibility  when  displaying 
data.  Extensible  Stylesheet  Language  (XSL)  can  be  used  to 
reorganize  and  reformat  the  data  to  simplify 
understandability.  In  fact,  innovative  stylesheets  could  be 
created  to  ensure  battle  commanders  could  visualize  a  common 
operational  picture  no  matter  what  system  they  were  using. 

-  Software  maintenance  cost  savings  could  be  realized 
through  the  use  of  COTS  based  XML-MTF  parsers.  The  COTS 
based  parsers  could  run  on  COTS  platforms  and  reduce 
reliance  on  costly  legacy  software  and  hardware. 

-  XML-MTF  could  utilize  the  same  network  transmission 
protocols  as  the  World  Wide  Web.  This  would  allow  the  XML- 
MTF  documents  to  be  transmitted  over  commercial  networks  as 
easily  as  HTML. 

-  XML-MTF  could  be  used  to  simplify  common  data  updates 
to  dissimilar  databases.  A  single  database  could  be  used  to 
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"push"  common  data  to  the  different  databases.  This  would 
ensure  the  data  was  consistent  throughout  all  the  databases. 
The  alternative  requires  individual  development  of  database 
updates  for  each  type  of  database  (i.e.,  AFATDs  database, 
MIDB,  TDBM  database,  etc.). 

XML-MTF  Mapping  is  the  primary  product  of  the  XML-MTF 
effort.  XML-MTF  Mapping  consists  of  the  definition  of  the 
formatting  rules  for  the  XML-MTF  messages.  These  rules  are 
included  in  Appendix  A  of  MIL-STD-6040 .  The  design  goals 
guiding  the  XML-MTF  Mapping  effort  are  [MAPOO] : 

•  XML-MTF  shall  be  easy  to  read  and  understand. 

•  XML-MTF  shall  be  designed  to  ensure  widespread 
military  adoption  by  accommodating  current  MTF 
standards . 

•  XML-MTF  should  be  easy  to  construct  from  basic  rules 
mapping  to  MTF  formats. 

•  XML-MTF  schemas  should  be  easy  to  construct. 

•  Operations  to  XML-MTF  messages  should  be  resilient 
to  schema  change. 

•  XML-MTF  shall  draw  as  much  as  possible  from  industry 
standards . 

The  details  of  how  XML-MTF  Mapping  is  being  developed 
can  be  found  in  the  XML-MTF  Mapping  Third  Public  Working 
Draft  [MAPOO] .  Below  is  an  example  mapping  a  portion  of  an 
MTF  message  to  XML-MTF  taken  from  an  XML-MTF  Update  Brief 
[XMLMPOO] ; 
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Figure  3:  MTF-XML  Mapping  Example 


This  XML-MTF  Mapping  Effort  has  developed  XML-MTF 
Translators  to  simplify  the  translation  process.  These 
translators  translate  from  MTF  to  XML-MTF  and  from  XML-MTF 
to  MTF.  The  XML-MTF  Mapping  Effort  continues  to  refine  and 
expand  the  XML-MTF  Mapping  and  is  pursuing  NATO  adoption  of 
this  process . 

Other  XML-MTF  mapping  information  can  be  found  in 
Lieutenant  Todd  Ehrhardt's  and  Captain  Brian  Lyttle's  thesis 
entitled  "Interconnectivity  Via  a  Consolidated  Type 
Hierarchy  and  XML"  [EHLYOl] . 

6.  Other  DoD  XML  Messaging  Efforts: 

Based  on  the  success  of  the  XML-MTF  initiative,  DoD 
has  initiated  the  XML-OTG  Mapping  initiative.  The  full  name 
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for  OTG  is  Operational  Specification  for  Over  the  Horizon 
Targeting  Gold  (OS -OTG) .  Like  USMTF,  OS-OTG  is  a  character 
oriented  messaging  standard  and  is  used  primarily  in  naval 
communications.  The  primary  differences  between  USMTF  and 
OS-OTG  are  in  the  message  structure,  syntax,  and  rules. 

The  similarities  between  USMTF  and  OS-OTG  allowed  those 
executing  the  XML-OTG  Mapping  effort  to  leverage  the 
previous  XML-MTF  Mapping.  The  first  XML-OTG  Mapping  Working 
Draft,  released  31  August  2000,  bears  a  remarkable 
similarity  to  the  XML-MTF  Mapping  Working  Draft.  In  those 
areas  where  USMTF  and  OS-OTG  are  the  same,  the  mapping 
approaches  used  in  the  XML-MTF  Mapping  were  adopted  in  the 
XML-OTG  Mapping  Working  Draft .  The  remainder  of  the  XML-OTG 
Working  Draft  identifies  the  various  differences  between 
USMTF  and  OS-OTG  and  then  identifies  corresponding  mapping 
approaches  to  resolve  those  differences. 

Other  messaging  formats  are  now  being  examined  to 
determine  if  they  are  candidates  for  XML  mapping.  The 
Variable  Message  Format  (VMF)  is  one  of  those  being 
investigated.  An  XML  mapping  to  VMF  is  more  difficult  to 
develop  because  VMF  is  a  "bit-oriented"  messaging  standard 
as  opposed  to  the  "character-oriented"  structure  of  USMTF. 
Also  most  fields  contained  in  USMTF  messages  are  fixed  in 
length  whereas  VMF  messages  have  fields  can  be  vary  in 
length.  A  VMF  can  be  only  a  few  bits  in  length  or  can  be 
several  Mbits  in  length. 
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There  are  four  alternative  XML  applications  being 
considered  for  VMF  [XMLVOO] : 

•  Case  1:  Develop  a  VMF  to  USMTF  to  XML-MTF  Mapping. 

•  Case  2:  Develop  a  VMF  to  XML-VMF  mapping. 

•  Case  3 :  Develop  generic  XML  Schema  to  support  all 
VMF  message  definitions. 

•  Case  4 :  Use  compressed  XML-VMF  document  using  COTS 
XML  compression  tools. 

A  decision  will  be  made  on  the  viability  of  XML-VMF 
mapping  once  these  alternatives  have  been  examined  in 
detail . 

7 .  XML  Mapping  Caveat 

Significant  problems  arise  with  all  of  these  XML  to 
message  format  mapping  initiatives.  Focus  must  be  placed  on 
development  and  adherence  to  the  standards  defining  the  XML 
mapping  (e.g.,  XML-MTF  mapping)  [HOP99] .  If  the  standards 
are  not  strictly  followed,  the  flexibility  provided  by  XML 
can  produce  different  system  implementations  of  the  XML 
mapping.  The  differences  in  implementation,  no  matter  how 
slight  would  results  in  severe  interoperability  disruptions. 

Detailed  specifications  must  be  developed  and  followed 
by  all  systems  implementing  the  XML  mapping.  This  is  the 
only  way  full  interoperability  can  be  achieved  between  all 
systems  using  XML. 
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P.  PREVIOUS  DATABASE  ANALYSES  METHODS 

1 .  Research  Preparation 

This  thesis  is  part  of  a  larger  NPS  research  team 
supporting  several  related  database  analyses  research  topics 
as  defined  in  the  Joint  Battle  Management  Initiative 
Assessment  Plan  Draft  [JBMIOO] . 

I  teamed  with  Mr.  Hamza  Zobair  to  research  the  XML 
Schema  Investigation  topic  as  described  in  Section  I.E.  The 
objectives  for  this  research  were: 

-  Determine  methods  for  assuring  scalability  of 
solution  to  legacy  and  migration  C4I .  This  requires  a 
method (s)  that  can  support  analysis  and  comparisons  of  both 
legacy  and  evolving  common  databases  like  JCDB, 

-  Determine  what  parts  of  a  legacy  system  view 
could  be  materialized  from  previous  shared  schemas.  This 
requires  the  identified  method (s)  to  be  able  to  identify 
common  elements  and  physical  schemas . 

Determine  how  to  materialize  those  parts 
relevant  to  such  an  assessment.  This  requires  the 
identified  common  data  elements  and  schemas  be  integrated 
into  a  global  common  schema. 

Our  original  research  methodology  was  to  jointly  search 
for  the  required  databases  and  any  XML  based  analysis 
schemas  we  could  find.  Once  found,  these  methods  would  be 
divided  between  the  two  of  us  and  used  to  examine/con^are 
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the  identified  databases.  I  was  responsible  for  attaining 
and  examining  the  AFATDS  database  and  JCDB,  Mr.  Zobair  was 
responsible  for  attaining  and  examining  the  MIDB  and  TDBM 
database . 

2 .  Roadblocks  Encountered  During  Research 

The  greatest  challenge  encountered  during  this  research 
effort  was  trying  to  obtain  a  copy  of  the  AFATDS  database. 
It  was  quickly  discovered  that  some  of  these  legacy  system 
databases  are  closely  held  products.  After  significant 
effort  on  my  part,  by  other  researchers  on  the  team,  and  by 
NFS,  the  AFATDS  database  proved  unattainable. 
Representatives  from  JBC  also  tried  and  failed  to  get  a  copy 
of  the  AFATDS  database  for  this  research  effort.  These 
efforts  to  get  the  AFATDS  database  spanned  several  months. 
The  JCDB,  however,  was  provided  in  multiple  versions  at  the 
start  of  the  research  effort.  Being  able  to  attain  only  one 
of  the  two  databases  required  to  execute  this 
analysis/comparison  research  efforts  presented  the  first 
major  roadblock  encountered  in  this  research  effort. 

The  second  major  roadblock  encountered  in  this  research 
effort  was  hit  while  searching  for  XML  based  database 
analysis  schemas  that  could  be  employed  in  analysis  of  the 
four  specified  databases.  Our  efforts  focused  on  searching 
electronic  technical  libraries  like  ACM,  IEEE,  Society  for 
Automotive  Engineers,  NFS's  Dudley  Knox  Library,  and  Defense 
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Systems  Management  College  Library  for  any  related  XML  based 
database  analysis  schemas.  The  Tank-Automotive  Research, 
Development,  and  Engineering  Center's  (TARDEC's)  Technical 
Library  was  also  employed  to  search  out  pertinent  database 
analysis  schema.  The  TARDEC  Technical  Library  has  (and 
used)  automated  search  resources  that  searched  several 
electronic  technical  libraries. 

These  searches  did  locate  several  technical  papers 
describing  database  analysis  techniques .  Most  were  written 
in  the  early  to  mid  1980 's.  These  papers  focused  on 
database  analysis  to  support  activities  like  data  mining, 
data  warehousing,  and  database  integration.  Most  papers 
examined  different  aspects  of  the  types  of  analysis  methods 
that  could  be  employed  to  support  this  research  effort.  The 
specific  methods  sought  were  ones  that  could  distinguish  and 
identify  common  data  elements  and  physical  schemas  between 
heterogeneous  C4I  databases. 

The  located  technical  papers  generally  fell  into  three 
categories : 

-  Data  Element/Data  Hierarchical  Searches:  These  papers 
provided  the  means  to  decompose  the  construct  of  a  database 
schema,  allowing  the  extraction  of  specific  data  elements 
and  parent-child  related  data  elements. 

Data  Element  Comparison:  These  papers  describe 
methods  of  comparing  multiple  databases  to  locate  common 
data  elements  in  multiple  databases. 


46 


-  Database  Integration:  These  papers  usually  examined 
methods  to  combine  two  databases  into  a  single  database. 

Only  one  technical  paper  was  found  that  described  a 
method  that  would  examine/compare  the  data  elements  and 
hierarchical  relationships  of  two  databases.  Entitled 
"SEMINT:  A  tool  for  identifying  attribute  correspondences  in 
heterogeneous  databases  using  neural  networks" [SEM99] ,  this 
paper  examined  most  of  the  database  analysis /comparison 
techniques  sought  in  this  research  effort. 

The  problem  with  all  of  these  papers  is  that  none 
employed  XML  to  support  the  database  analysis  and 
comparison.  This  was  not  a  great  surprise  since  most  of  the 
papers  were  written  long  before  the  1996  inception  of  XML. 
But  this  led  to  the  second  major  roadblock  encountered  in 
this  research  effort:  How  can  an  XML  schema  investigation  of 
databases  be  conducted  when  no  XML  based  analysis  methods 
can  be  found? 

3 .  An  Opportunity  for  a  New  Analysis  Method 

Faced  with  these  two  major  roadblocks,  the  objective 
for  this  thesis  was  refocused  towards  examining  how  XML 
could  be  employed  in  the  development  of  an  XML  based 
database  analysis  and  comparison  method  that  would  still 
meet  the  original  objectives  of  this  research  effort.  With 
the  continuing  development  (and  refinement)  of  XML  and  its 
associated  XML  based  capabilities  (i.e.,  XSL,  DOM  APIs, 
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Infoset,  etc.),  the  tools  are  available  to  define  a  new  XML 
based  C4I  database  analysis  and  comparison  method.  The 
remainder  of  this  thesis  will  describe  and  demonstrate  this 
new  XML  based  C4I  database  analysis/comparison  method.  An 
additional  objective  for  this  method  was  to  ensure  it  had 
broader  application  beyond  C4I  databases.  This  new  method 
can  be  used  to  analyze  and  compare  any  XML  document. 
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IV.  XML  BASED  ANALYSIS  AND  COMPARISON  METHOD  DESCRIPTION 

A.  INTRODUCTION  TO  PROCESS 

The  original  JBC/NPS  research  task  was  to  determine 
methods  to  seek  out  XML  methods  for  assuring  scalability  of 
XML  solutions  to  legacy  and  migration  to  C4I  database 
schemas  [JBMIOO] .  As  was  briefly  described  in  the  previous 
section  there  are  no  XML  based  methods  available  to  analyze 
database  schemas.  To  ensure  that  the  overall  objective  of 
this  research  effort  was  met  a  new,  XML  based  database 
analysis  and  comparison  method  has  been  developed  and  will 
be  described  in  this  thesis. 

1.  Focus  of  Process 

This  process  sought  to  demonstrate  how  XML  can  be 
exploited  to  analyze  and  compare  common  schemas  between 
heterogeneous  databases.  It  focused  on  the  use  of  XML  COTS 
software  whenever  possible  to  execute  the  analysis  and 
comparison.  This  process  also  sought  to  reduce  reliance  on 
any  legacy  software. 

The  XML  based  analysis  and  comparison  process 
description  was  divided  into  a  sequential  step  by  step 
process.  Each  step  description  began  with  a  description  of 
the  components  necessary  to  execute  the  process.  These 
component  descriptions  focus  on  the  individualized  database 
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views  to  be  analyzed  along  with  the  software,  tools,  and/or 
XML  resources  required  to  execute  the  analysis. 

The  process  is  described  using  the  defined  component 
and  reinforced  using  examples  whenever  possible.  The  most 
detailed  of  these  examples  occur  at  the  end  of  the  process 
where  views  of  the  JCDB  and  MIDB  are  analyzed  and  compared 
using  COTS  based  tools .  The  products  of  these  analyses  and 
the  code  developed  to  execute  the  analyses  are  included  in 
the  appendices  of  this  thesis. 

In  some  steps  alternative  analysis  paths  are  available 
to  the  recommended  analysis  path.  When  this  happens  these 
alternative  paths  are  briefly  described,  highlighting  their 
benefits/  shortfalls  and  why  they  weren't  included  as  part 
of  the  recommended  process . 

2 .  Database  Analysis  Aspects  Not  Covered 
The  JCDB  and  MIDB  were  not  analyzed  as  part  of  this 
research  effort .  This  is  because  the  unique  system  specific 
database  software  was  not  available  and  the  size  of  the  two 
databases  prevented  detailed  coirparisons  using  existing 
computing  resources.  This  is  also  because  some  the  database 
infoimiation  was  unavailable.  Instead  this  research  effort 
focuses  on  smaller  views  of  portions  of  the  databases. 
These  smaller  views  actually  help  facilitate  the  description 
of  the  analysis  process . 
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Since  required  database  software  (i.e.,  Informix, 
Sybase,  etc.)  was  unavailable  or  could  not  be  used,  examples 
supporting  that  particular  step  had  to  be  built  manually. 
When  this  was  done  it  is  identified  as  being  a  manual 
equivalent.  The  intent  was  to  provide  as  detailed  exanples 
as  possible  and  to  support  the  description  of  the  process. 

Detailed  description  and  analysis  of  the  JCDB  and  MIDB 
are  not  provided  as  part  of  the  research  effort .  This  is 
because  limited  information  was  available  on  these 
databases.  This  was  especially  true  for  the  MIDB.  The 
portions  of  the  MIDB  extracted  to  build  the  MIDB  View  had  to 
be  built  solely  from  the  MIDB  Data  Dictionary.  There  were 
no  entity  relationship  diagrams  available  to  support 
definition  of  the  database  hierarchy.  These  relationships 
were  drawn  from  the  data  dictionary. 

Analyzing  the  entire  JCDB  would  also  be  difficult  due 
to  its  size.  A  JCDB  View  was  built  to  simplify  the  analysis 
description.  Also  to  strengthen  the  process  description  it 
was  best  to  have  a  JCDB  View  equivalent  in  size  to  the  one 
built  for  the  MIDB. 

B.  DATABASE  REVIEW  STEP 

This  step  will  be  where  the  databases  to  be  analyzed 
are  assembled  and  evaluated  for  completeness .  The  goal  for 
this  step  is  to  have  both  databases  roughly  at  the  same 
level  of  detail.  The  term  "level  of  detail"  simply  means 
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that  the  same  type  and  detail  of  information  is  available 
for  each  database  to  be  analyzed  and  compared.  For  example, 
if  one  database  contains  information  describing  the  data 
type  of  the  database  attributes  and  the  other  database 
doesn't  then  it  will  be  impossible  to  conduct  a  comparison 
of  attribute  data  types  between  the  two  databases.  It  is 
best  to  balance  the  level  of  detail  between  databases 
whenever  possible.  This  will  ensure  the  analysis  and 
comparison  is  equitably  executed  between  both  databases. 

Balancing  the  level  of  detail  requires  close  inspection 
of  all  documentation  available  on  each  database.  Generally 
the  available  documentation  is  available  in  two  forms. 

First  is  the  database's  Data  Dictionary  that  provides 
database  schema  and  implementation  infoirmation  to  support 
standardized  database  development  and  data  usage  [JDDOO] 
The  data  dictionary  provides  detailed  information  on  the 
entity  table  and  associated  attribute  and  the  associated 
relationship  descriptions  between  then.  For  especially 
large  databases,  like  JCDB  and  MIDB,  using  these 

relationship  descriptions  to  identify  relationships  between 
more  than  a  few  entities  is  difficult. 

To  help  alleviate  this  problem  large  databases  also  use 
Entity-Relationship  Diagrams  as  the  second  form  of  database 
documentation.  The  diagrams  provide  graphical 

representations  of  the  relationship  hierarchy  built  into  the 
database.  For  the  purposes  of  this  research  these  entity 
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relationship  diagrams  will  focus  on  the  logical 
representation  of  the  data.  This  logical  representation 
represents  the  inherent  structure  of  the  data,  independent 
of  the  individual  application  [DOD98] . 

To  balance  the  level  of  detail  a  visual  inspection 
review  and  comparison  between  each  of  the  data  dictionaries 
and  entity  relationship  diagrams  must  be  conducted.  If 
roughly  the  same  information  is  available  between  the 
databases  we  can  proceed  to  the  next  step  in  the  process. 

When  the  difference  in  the  level  of  detail  between  the 
databases  is  significant  it  can  jeopardize  the  analysis 
effort.  There  are  two  alternatives  available  if  this  should 
be  the  case: 

One  alternative  would  be  to  limit  the  subsequent 
analysis  and  comparison  to  only  those  portions  of  the 
databases  that  have  the  same  level  of  detail.  For  example, 
if  entity  relationship  information  is  not  available  for  one 
database,  the  analysis  and  comparison  can  be  limited 
executing  an  entity  to  entity  comparison. 

A  second  alternative  would  be  to  develop  additional 
detail  in  the  database  lacking  detail  through  searches  for 
additional  documentation  or  consulting  with  subject  matter 
experts  (SMEs) .  This  additional  data,  if  discovered,  may 
have  to  be  manipulated  into  a  format  that  is  comparable  to 
the  other  database. 
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1 .  JCDB/MIDB  Comparison 

In  this  research  effort  the  JCDB  and  MIDB  were  chosen 
for  comparison.  Smaller  portions  of  the  two  databases  were 
chosen  to  execute  this  analysis  and  comparison  effort.  This 
was  done  for  the  following  reasons: 

Database  Size:  The  extremely  large  size  of  the  two 
databases  would  add  unneeded  complexity  and  confusion  to  the 
description  of  this  analysis  and  comparison  process.  It  was 
best  to  focus  on  portions  of  the  databases  that  can  best  be 
used  to  describe  the  process. 

Limited  Access  to  Data:  Specific  software  called 
"ERwin"  was  required  to  view  the  JCDB  logical 
representations .  This  researcher  was  only  able  to  gain  use 
of  a  limited  two-week  trial  version  of  the  ERwin  viewing 
software.  This  trial  version  of  the  software  limited  the 
amount  of  entity  relationship  detail  that  could  be  extracted 
from  the  JCDB  logical  representation. 

MIDB  Entity  Relationship  Diagram:  The  entity 
relationship  diagrams  for  the  MIDB  could  not  be  located  for 
this  research  effort.  The  logical  representations  of  the 
smaller  portions  of  the  database  built  had  to  be  constructed 
from  the  MIDB  Data  Dictionary  relationship  descriptions.  It 
would  have  been  impossible  to  build  the  entity  relationship 
diagrams  for  the  entire  MIDB.  For  the  purposes  of  this 
research  effort  I  was  required  to  make  certain  assumptions 
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in  the  development  of  these  entity  relationship  diagrams 
that  could  result  in  slight  deviations  from  the  actual 
relationships  contained  in  the  MIDB. 

To  develop  these  entity  relationships  diagrams  the  DoD 
8320.1-M-l  Data  Standardization  Procedures  and  the 
Integration  Definition  for  Info2nnation  Modeling  (IDEFIX)  was 
used  as  a  means  to  standardize  the  logical  representation  of 
the  database  entities. 

DoD8320  provides  the  procedures  for  developing, 
approving,  implementing,  and  maintaining  DoD  data  standards. 
These  data  standards  provide  the  framework  for  how  the  data 
will  be  formatted  for  implementation  within  the  information 
system  [DOD98] .  The  IDEFIX  defines  how  to  produce  a 
graphical  information  model  that  represents  the  structure 
and  semantics  of  information  within  an  environment  or  system 
[IDEF93] . 

2 .  JCDB  View 

To  build  the  JCDB  View,  portions  of  the  JCDB  were 
extracted  from  the  data  dictionary  based  on  the  limited 
entity  relationship  diagrams  available.  The  entity 
relationship  diagrams  were  reviewed  and  modified  slightly  to 
better  conform  to  DoD  8320  and  IDEFIX.  Examples  of  the 
extracted  portions  from  the  JCDB  Data  Dictionary  and 
associated  entity  relationship  diagram  can  be  found  in 
Appendix  A. 
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3. 


MIDB  View 


After  extensive  review  of  the  MIDB  Data  Dictionary, 
portions  were  extracted  that  were  similar  in  nature  to  the 
extracted  portions  of  the  JCDB.  These  portions  focused  on 
the  Tar^st  Assessment  and  Battle  Damage  Assessment  Report 
(BDAR) . 

Since  no  MIDB  entity  relationship  diagrams  were 
,  one  had  to  be  developed  from  the  relationships 
described  in  the  data  dictionary.  Appendix  B  contains 
examples  of  the  extracted  portions  of  the  data  dictionary 
and  the  developed  entity  relationship  diagram. 

4 .  Conclusion 

With  the  completion  of  this  step  there  are  now  two 
database  views  that  contain  approximately  the  same  "level  of 
detail".  As  describes  earlier,  this  will  ensure  subsequent 
analyses  and  comparisons  are  based  on  comparable  data. 

C.  DATABASE  CONVERSION  TO  XML 

The  two  or  more  databases  with  roughly  the  same  level 
of  detail,  developed  in  the  last  step  must  now  be  converted 
into  XML  documents.  This  is  relatively  simple  process  if 
the  database  software  (i.e.,  Informix,  Sybase,  etc.)  retains 
i^^t®9i^9-ted  XML  translation  capability.  As  described  in 
Section  D,  many  of  the  database  software  manufacturers  are 
integrating  XML  translators  in  one  form  or  another  to 
support  internet  applications  of  their  databases.  For  the 
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purposes  of  this  research,  the  conversion  to  XML  provides 
the  common  basis  upon  which  the  analysis  and  coirparison  can 
be  executed.  This  conversion  also  supports  one  of  the 
primary  objectives  of  this  research  effort  to  bring  XML  into 
the  analysis  and  comparison  process. 

1.  Database  to  XML  Translation 

If  the  database  software  in  cjuestion  has  an  XML 
translation  capability,  then  the  XML  translation  of  the 
database  to  be  analyzed  requires  the  analyst  to  execute  the 
translation  process  as  specified  by  the  database  software. 
Before  converting  the  databases,  each  database  to  XML 
translators  should  be  reviewed  to  confirm  they  conform  to 
the  same  XML  Recommendation.  Currently,  only  XML 
Recommendation  1.0  has  been  released.  In  the  future,  as  XML 
Recommendation  1.0  is  updated,  there  may  be  situations  where 
older  database  software  products  maintain  translators  built 
to  outdated  recommendations  while  newer  database  XML 
translators  are  built  to  the  latest  recommendation. 

It  is  critical  that  automated  methods,  like  the  built- 
in  XML  translators,  be  used  to  translate  databases  like  JCDB 
and  MIDB.  The  size  and  complexity  of  these  databases  would 
make  any  manual  XML  conversion  impossible.  Additionally, 
the  XML  document  equivalent  of  the  database  would  be  even 
larger.  In  Joint  Battle  Management  Initiative  (JBMI) 
experiments  conducted  in  July  2000  it  was  estimated  that  the 
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XML  equivalent  growth  from  a  USMTF  message  was  approximately 
10  to  1.  While  USMTF  is  not  a  database,  it  still  has  to 
maintain  specific  data  type  and  structure  to  convey  a 
specific  message.  Likewise  a  database  maintains  specific 
entity  and  attributes  in  a  specific  structure. 
Additionally,  the  database  must  maintain  the  relationships 
between  these  entities  to  convey  the  hierarchical 
parent/child  relationships.  It  can  be  hypothesized  that  the 
XML  growth  for  relational  databases  like  JCDB  and  MIDB  would 
be  even  greater  than  10  to  1.  This  was  one  of  the  reasons 
smaller  views  of  the  databases  were  extracted  for  use  in 
this  research  project. 

Once  translated,  portions  of  each  XML  document  should 
be  manually  examined  to  ensure  the  translations  were 
executed  as  expected.  This  manual  inspection  would  require 
cross-checking  between  the  database  data  dictionary,  the 
entity  relationship  diagrams,  and  the  XML  document  to  ensure 
the  entities,  attributes,  and  hierarchical  relationships  are 
captured  in  the  XML  documents.  Only  one  or  two  portions  of 
the  database  and  XML  document  needs  to  be  examined  to  ensure 
the  translation  was  successfully  conpleted.  This  step  is 
completed  once  all  the  databases  have  been  converted  into 
XML  documents  and  they  have  been  successfully  reviewed. 
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2 .  XML  Translation  Alternative 

An  alternative  automated  translation  process  is 
required  if  the  particular  database  software  product  does 
not  have  an  XML  translation  capability  or  when  the  manual 
inspection  of  the  translated  XML  document  resulted  in 
unacceptable  documents. 

This  alternative  focuses  on  utilizing  Microsoft's  Open 
Database  Connectivity  (ODBC)  APIs  built  into  most  database 
software  products.  The  ODBC  APIs,  based  on  Structured  Query 
Language  (SQL) ,  provides  call  functions  that  can  be  used  by 
database  software  products  to  manipulate  the  particular 
database  [ODBCWP]  into  an  ODBC  structure.  Then  a  shareware 
product  called  0DBC2XML  can  be  used  to  convert  an  ODBC 
forroatted  database  to  XML.  Being  that  0DBC2XML  is  shareware 
there  is  no  assurance  that  the  converted  XML  document  fully 
represents  the  database.  A  thorough  examination  of  XML 
documents  must  be  made  to  ensure  its  validity.  For  the 
purposes  of  this  research  this  conversion  alternative  will 
not  be  examined  further. 

3 .  JCDB  and  MIDB  to  XML  Translations 

Without  access  to  any  of  the  necessary  database 
software  products  (or  the  specific  databases)  it  was 
impossible  to  execute  either  of  these  translation 
alternatives .  This  does  not  impact  this  research  since  as 
described  earlier,  this  step  in  the  process  is  an  automated 
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process  using  resources  already  built  into  the  database 
software  product . 

As  an  alternative  the  XML  documents  to  be  used  in  this 
research  project  were  manually  developed  from  the  JCDB  and 
MIDB  views  included  in  Appendix  A  and  B,  Due  to  the  lack  of 
data  on  the  JCDB  and  MIDB,  certain  assumptions  had  to  be 
made  when  developing  these  XML  documents.  These  assuitptions 
centered  on  defining  certain  hierarchical  structures  of  the 
XML  document  and  the  data  contained  in  the  XML  documents. 
These  assumptions  do  not  impact  objectives  of  the  analysis 
and  comparison  process,  which  is  to  demonstrate  how  common 
XML  based  schema  can  be  extracted.  Another  assumption  made 
while  developing  these  XML  documents  was  to  exclude  the 
development  of  DTDs  or  XML  Schemas.  Including  or  omitting 
the  DTDs  and  Schemas  do  not  impact  this  analysis  and 
comparison  process.  In  the  case  of  this  research  effort 
they  only  add  additional  complexity  that  might  distract  from 
the  process  description. 

4 .  Conclusion 

This  step  is  completed  with  the  development  of  multiple 
well -formed  and  comparable  XML  documents.  The  JCDB  and  MIDB 
XML  documents  are  included  in  Appendix  C  and  Appendix  D. 
These  documents  provide  a  common  basis  upon  which  analysis 
and  comparisons  of  two  (or  more)  databases  can  be  executed. 
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D.  ENTITY/ATTRIBDTE  ANALYSIS  AND  COMPARISON 


As  described  in  Section  I,  the  original  objective  of 
this  project  was  the  execution  of  an  XML  based  analysis  and 
comparison  of  the  AFATDS,  GCCS  TDBM,  GCCS  13  (MIDB) ,  and  the 
JCDB.  I  teamed  with  Mr.  Hamza  Zobair  to  accomplish  this 
task.  Due  to  difficulties  described  Section  III.F.2  we  each 
decided  to  broaden  our  research  topic  to  define  our  own 
analysis  processes  of  the  JCDB  and  MIDB.  Mr.  Zobair  chose 
to  research  a  process  to  analyze  and  compare  database 
entities  and  attributes.  I  chose  to  research  a  process  to 
analyze  and  compare  the  hierarchical  relationships  of  the 
databases.  Both  analysis  methods  are  required  when 
comparing  and  locating  common  portions  of  databases. 

1.  Introduction 

This  step  in  the  overall  XML-based  analysis  and 
comparison  process  was  researched  and  described  by  Mr.  Hamza 
Zobair  in  his  thesis  entitled:  "An  Approach  for  Matching 
Corresponding  Attributes  in  ,  Legacy  Heterogeneous  DoD 
Databases"  [HZOl] .  This  process  to  conduct  an  entity  and/or 
attribute  analysis  and  comparison  will  only  be  briefly 
described  in  this  thesis.  I  highly  recommend  reading  Mr. 
Zobair 's  well -written  thesis  for  the  full  description  of 
this  analysis  process. 
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2 .  Process  Description 

This  step  in  the  overall  XML  based  analysis  can  be 
conducted  prior  to  or  in  parallel  with  the  previous  steps 
described  so  far.  The  basis  for  comparing  the  entities 
and/or  attributes  of  databases  is  the  entity  and  attribute 
tables  located  in  the  database  data  dictionary.  The  first 
step  in  the  process  requires  the  restructuring  of  the  tables 
into  comparable  structures.  Depending  on  the  amount  of 
restructuring  and  size  of  the  tables,  this  can  be  a  very 
time  consuming  process.  It  is  recommended  that  automated 
methods  be  used  whenever  possible . 

Once  restructured,  the  tables  are  conpared  using 
automated  comparison  tools.  These  tools  would  search  and 
compare  the  tables  and  identify  potential  matches  of  common 
entities  and/or  attributes.  These  tools  employ  user 
developed  thesauruses  and  data  clusters  as  the  basis  to 
execute  the  entity  and  attribute  comparisons. 

Once  potential  matches  are  identified,  the  matching 
criteria  are  refined  based  on  a  manual  review  of  the 
matches.  A  final  analysis  is  then  conducted  to  identify  the 
best  possible  matches.  These  matches  are  then  reviewed  by 
domain  experts  to  validate  or  discount  the  matches. 

3 .  Conclusion 

Mr.  Zobair's  research  examined  the  attribute  tables  of 
the  JCDB  and  MIDB.  These  attribute  tables  are  significantly 
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more  complex  than  the  entity  tables.  The  same  analysis 
process  would  be  used  to  analyze  and  identify  common 
entities . 

These  identified  common  entity  and  attributes  become 
the  "search  keys"  critical  to  the  remainder  of  the  database 
analysis  and  comparison.  The  use  of  these  search  keys  will 
significantly  simplify  the  search  of  the  extremely  large  XML 
documents  built  from  the  databases. 

Finally,  it  must  be  stressed  that  to  fully  understand 
this  process  it  is  important  that  Mr.  Zobair's  thesis  be 
reviewed . 

E.  HIERARCHICAL  EXAMINATION 

At  this  point  in  the  process  it  is  important  to  review 
what  has  be  an  developed  so  far: 

•  Establishment  of  two  or  more  databases  that  have 
been  reviewed  and  determined  to  be  roughly 
comparable . 

•  Development  of  XML  documents  built  from  the 
comparable  databases.  If  built  from  the  JCDB  and 
MIDB,  these  documents  would  be  very  large. 

•  A  list  of  search  key  developed  through  the  entity 
and  attribute  analysis. 

What  is  required  now  is  an  automated  process  to  search 
these  large  XML  documents  to  locate  desired  portions  of  the 
database  based  on  given  search  keys .  Once  the  desired 
entities  and  or  attributes  are  located  this  process  must 
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then  be  able  to  extract  and  present  them  to  an  SME  that  has 
a  detailed  understanding  of  that  portion  of  the  databases. 

This  identification  and  extraction  process  must  be  able 
to  maintain  the  hierarchical  composition  of  the  XML 
document.  This  is  the  overall  objective  of  the  research 
effort,  identification,  extraction,  and  comparison  of 
specific  hierarchical  relationships  of  multiple 
heterogeneous  databases . 

One  of  the  reasons  for  converting  the  databases  to  XML 
documents  is  that  there  are  XML  based  tools/resources 
available  to  examine  and  manipulate  the  hierarchical 
composition  of  XML  documents.  The  key  XML  based  resource  to 
be  used  in  this  research  effort  is  called  the  Document 
Object  Model  (DOM) . 

1.  What  is  a  DOM? 

From  the  W3C  DOM  web  page,  the  5OM  is  defined  as  "...a 
platform  and  language  -  neutral  interface  that  will  allow 
programs  and  scripts  to  dynamically  access  and  update  the 
content,  structure,  and  style  of  documents.  The  document 
can  be  processed  and  the  results  of  that  processing  can  be 
incorporated  back  into  the  present  page."  [W3CWP]  More 
simply  put,  the  DOM  is  a  specification  that  defines  how  an 
XML  (or  HTML)  document  can  be  parsed  into  a  node  tree 
representation  of  that  document  and  analyzed. 
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The  node  tree  representation  of  the  document  begins 
with  the  root  element  of  the  XML  document  set  as  the  root  of 
the  tree.  The  children  of  the  root  branch  out  to  nodes. 
They  are  called  "nodes"  because  each  of  the  XML  document 
components  is  parsed  into  their  own  individual  node.  Each 
node  object  implements  a  node  interface.  The  following 
figure  shows  all  the  node  interfaces  that  can  be  used  to 
build  a  DOM  node  interface  tree  [XMDBOO] . 


Figure  4:  DOM  Node  Tree  Components 


These  node  interfaces  provide  the  points  where  the  DOM 
node  tree  can  be  navigated  and  manipulated.  Scripting 
languages,  like  JavaScript,  can  be  used  to  invoke  DOM  APIs 
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that  provide  the  means  to  move  through  the  tree  and  modify 
it.  An  example  how  this  works  will  be  described  later. 

a)  DOM  Recommendations 

The  DOM  Recommendations  are  managed  by  the  W3C. 
The  W3C  is  a  consortium  of  over  500  members  from  34 
countries  that  produce  standards  setting,  interoperable 
technologies  through  consensus.  Their  membership  is 
comprised  of  industry,  government,  citizens  groups,  and 
other  organizations  committed  to  the  development  of  the  Web 
[W3CWP] .  The  objective  document  the  W3C  publishes  is  the 
"recommendation"  as  the  defining  and  locked  document  that 
describes  a  specific  web  based  technology  (e.g.,  DOM).  When 
developing  the  recommendation,  a  W3C  technical  working  group 
made  up  of  experts  in  that  technical  field,  posts  the 
working  documents  called  specifications  to  the  web  site. 
Anyone  is  welcomed  to  submit  comments  on  the  specifications. 
Through  consensus  the  working  group  deteimiines  what 
specification  modifications  are  required  based  on  their  own 
individual  developments  and  submitted  comments.  Once  a 
specification  is  finalized  and  approved  by  the  working  group 
it  is  posted  as  a  "recommendation".  The  DOM  Recommendations 
provide  the  interface  definitions  for  the  DOM  API  libraries. 
The  W3C  has  posted  three  levels  of  DOM  Recommendations  and 
Specifications. 
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The  DOM  Level  1  Recommendation,  issued  on  1  Oct 
1998,  defines  the  foundation  set  of  interfaces  to  navigate 
and  manipulate  the  XML  (and  HTML)  documents.  A  second 
edition  of  the  DOM  Level  1  specification  is  now  under 
development  and  is  posted  on  the  W3C  Web  Site  for  review. 

The  DOM  Level  2  Recommendation  builds  upon  the  DOM 
Level  1  Recommendation  by  defining  additional  interface 
definitions.  It  includes  a  style  sheet,  object  model,  and 
defines  functionality  for  manipulating  the  style  information 
attached  to  a  document.  It  also  provides  support  for  XML 
Namespaces  [RCWP] .  The  Level  2  Recommendation  is  comprised 
of  the  Core  View,  Style,  Event,  Traversal -Range 
Recommendations  all  issued  13  November  2000. 

The  DOM  Level  3  Specification  (not  a 
recommendation  yet)  will  define  loading  and  saving 
interfaces  and  content  models  with  validation  support.  Also 
to  be  addressed  will  be  document  views,  formatting,  key 
events,  and  event  groups.  The  Level  3  Specification  Working 
Drafts  posted  are  the  Core  (posted  1  September  2000) ; 
Content  Models  and  Load  and  Save  Interfaces  (posted  9 
February  2001) ;  and  Views  and  Formatting  (posted  15  November 
2000)  . 


67 


Example 

Le  of  a  DOM  Node  Tree  can  be  built  from 
document  (adapted  from  example  in 

id="123" >M1</Tank> 


objects.  The  NodeList  object  controls  a  list  of  nodes  below 
it.  This  NodeList  will  change  as  nodes  are  added  or 
deleted.  The  NodeNamedMap  controls  unordered  sets  of  nodes 
referenced  by  their  attribute  names.  The  NodeNamedMap  also 
changes  based  on  the  addition  and  deletion  of  nodes. 

c)  Examples  of  Interfaces 

The  following  are  examples  of  the  interfaces 
related  to  various  node  objects.  The  most  fxmdamental 
object  in  the  DOM  is,  of  course,  the  Node.  The  node  retains 
certain  properties  and  methods  that  will  allow  the  traversal 
of  the  tree,  obtaining  specific  information  on  the  node,  and 
manipulating  the  node.  The  following  are  a  few  of  the  node 
properties  (adapted  from . [XMDBOO]  )  : 


Property 

Description 

nodeName 

_ 

Returns  value  of  specified  node. 

nodeType 

Returns  type  of  specified  node. 

childNodes 

Returns  the  node  list  of  specified  node. 

If  no  children,  returns  empty  node  list. 

previous Sibl ing 

Node  immediately  before  current  node. 

nextSibling 

Node  following  current  node. 

Using  the  properties  listed  in  the  table  the 
following:  "previousSibling.nodeName"  would  return  the  name 
of  the  previous  sibling's  name.  The  employing  of  the 
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properties  "nextSibling.nodeValue"  would  return  the  value  of 
the  following  sibling  node. 

These  two  examples  provide  demonstrations  of  how 
the  DOM  can  be  navigated.  The  properties  " previous S ibl ing " , 
"next Sibling",  "parentNode" ,  "f irstChild" ,  and  "lastChild" 
are  the  primary  means  used  to  navigate  through  the  DOM  node 
tree. 

Besides  the  properties,  the  node  also  has  methods 


that  can  be  used  to  manipulate  the  DOM.  The  following  table 
provides  some  examples : 


Method 

Action 

insertBefore (newChild, 

Inserts  new  child  before  current 

refChild) 

reference  child. 

replaceChild (newChild, 

Replaces  old  child  with  new  child. 

oldChild) 

Returns  the  old  child. 

cloneNode (deep) 

Returns  a  duplicate  of  node.  Deep 

is  a  boolean  value.  If  false, 

returns  node.  If  true,  the  node  and 

entire  subtree  under  the  node  is 

returned. 

The  properties  and  methods  listed  are  only  a  few 
of  those  available  in  the  DOM  Recommendations  and 
Specifications . 
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d)  Products  Employing  DOM  APIs 

With  the  DOM  Recommendation  (DOM  Level  1)  only 
being  available  for  just  over  two  years  only  a  few 
commercially  available  DOM  tools  and  applications  have  been 
developed.  Probably  the  most  basic  and  most  xmiversally 
available  is  Microsoft's  Internet  Explorer  5.0,  which  has 
integrated  an  XML  parser  and  DOM  APIs  (Note:  Netscape  also 
has  integrated  a  limited  XML  parser  and  DOM  APIs)  .  The 
reason  Microsoft  has  been  able  to  integrate  XML  parsers  and 
DOM  APIs  before  other  manufacturers  is  because  they  began 
their  integration  efforts  long  before  the  actual 
recommendations  had  been  approved.  In  some  cases,  they 
risked  building  in  XML  and  DOM  capabilities  based  only  on 
requirement  documents. 

Besides  Internet  E^^lorer,  there  are  other  DOM 
tools  available.  A  few  of  these  DOM  products  were  listed  on 
the  web.  Even  though  most  of  these  DOM  products  have  unique 
platform/ software  requirements  that  prevented  detailed 
investigations  in  this  research  effort  they  do  demonstrate 
that  DOM  APIs  are  being  widely  adopted  for  use  in  the  XML 
community.  As  the  other  DOM  Recommendations  are  released 
the  number  of  DOM  products/application  will  surely  grow. 

e)  Problems  With  DOM 

The  primary  problem  with  DOM  APIs  is  that  when  a 
DOM  node  tree  is  created  it  can  be  5-10  times  the  size  of 


71 


the  originating  XML  document.  Earlier  I  hypothesized  that 
an  XML  document  built  from  a  database  like  JCDB  could  easily 
be  10  times  larger  [XMDBOO] .  Combine  the  growth  from 
database  to  XML  document  to  DOM  node  tree  and  the  final  DOM 
tree  could  be  100  times  the  size  of  the  original  database. 

Another  problem  with  using  DOM  APIs  is  that  they 
are  still  evolving.  There  are  still  several  specifications 
defining  new  APIs  undergoing  revision.  Additionally,  the 
DOM  Level  1  Recommendation  is  already  undergoing  revision  in 
its  second  edition.  Potential  developers  desiring  to 
integrate  DOM  APIs  may  continue  to  wait  until  all  the  DOM 
APIs  become  more  stable. 

f)  DOM  Problem  Solutions 

Memory  Usage:  The  DOM  memory  usage  will  become 
less  of  a  problem  as  the  computing  technologies  continue  to 
grow.  Personal  computers  with  1.5  Ghz  processors,  300  MB 
RAM,  100  GB  hard  disks,  and  500  GB  DVD  read/write  drives  can 
be  purchased  today.  These  computing  capacities  can  be 
expected  to  double  each  year  for  the  next  several  years . 
With  this  level  of  computing  power/ capacities  available  to 
anyone,  the  size  of  the  DOM  should  not  be  a  problem. 

Unstable  Recommendations:  Recognizing  the 
potential  of  DOM  APIs,  large  software  developers,  like 
Microsoft  and  Netscape,  have  already  integrated  DOM 
capabilities  into  their  browsers.  This  was  even  before  any 
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recommendations  had  been  approved.  As  XML  grows  in 
acceptance,  so  will  the  use  of  DOM.  Software  developers 
will  have  to  commit  to  incoi^porating  DOM  APIs  into  their 
products  if  they  want  to  take  full  advantage  of  the  XML. 

Alternative  to  Using  DOM:  Another  method  available 
to  search  and  manipulate  XML  documents  is  to  use  the  Siirple 
API  for  XML  (SAX) .  The  SAX  is  an  event-based  interface  that 
serially  processes  XML  documents  and  notifies  the 
application  calling  the  SAX  when  a  certain  event  has 
occurred.  The  DOM  on  the  other  hand  loads  the  entire 
document  into  memory  and  manipulates  it .  The  SAX ' s  serial 
processing  approach  eliminates  the  memory  burden  associated 
with  the  DOM.  It  also  allows  the  SAX  to  process  an  XML 
document  of  any  size.  Another  benefit  to  using  SAX  is  that 
it  provides  several  APIs  to  navigate  and  manipulate  an  XML 
document . 

The  use  of  SAX  does  have  shortcomings.  First  is 
that  SAX  is  not  associated  with  any  standards  and/or 
consortium  bodies  like  the  W3C.  As  a  result,  the  SAX  has  no 
design  stability  since  the  SAX  can  be  changed  at  any  time. 
Another  problem  with  using  SAX  is  that  complex  searches  of 
XML  documents  are  difficult.  Since  the  SAX  process  the  XML 
document  serially,  multiple  searches  might  have  to  be  made 
to  find  a  single  element.  For  exanple,  suppose  a  parent 
element  of  a  child  element  must  be  found.  The  SAX  would 
have  to  process  the  XML  document  to  find  the  child  element 
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and  then  process  it  again  to  find  the  parent  element.  This 
will  increase  the  SAX's  overall  processing  time  of  an  XML 
document . 


g)  Selection  of  DOM  API 

During  this  research  effort  both  the  DOM  and  SAX 
had  to  be  examined  to  determine  which  would  best  serve  this 
analysis  and  comparison  process.  The  DOM  was  chosen  because 
it  presented  more  capability  to  navigate  and  manipulate  an 
XML  document.  Additionally,  the  DOM's  memory  usage  problem 
would  not  impact  this  research  effort  since  smaller  views  of 
the  JCDB  and  MIDB  were  being  used. 

2 .  Process  Description  Introduction 

The  objective  of  this  step  in  the  process  is  to  employ 
DOM  APIs  to  examine  and  manipulate  the  XML  documents  built 
from  the  database  views.  This  can  be  accomplished  with  the 
development  of  scripting  code  to  invoke  the  DOM  APIs.  This 
was  accomplished  using  relatively  few  lines  of  code.  The 
majority  of  the  code  was  necessary  to  account  for  the  output 
and  storage  functions  that  aren't  yet  available  because  the 
associated  DOM  Recommendations  have  just  been  approved  or 
are  nearing  approval.  Once  all  the  DOM  recommendations  are 
incorporated  into  a  software  application,  it  will  be  a 
simple  task  to  streamline  the  code  to  make  it  much  more 
efficient. 
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Microsoft's  Internet  Explorer  with  its  built-in  XML 
parser  and  DOM  APIs  were  chosen  as  the  software  application 
to  be  used  in  this  process.  At  this  time  there  are  no  other 
commercially  equivalent  XML  parsers  available  for  use  on  a 
standard  personal  computer  using  Windows  '95.  Internet 
Explorer  4.0  and  Netscape  6.0  only  have  limited  XML 
capabilities.  There  are  some  shareware  XML  parsers 
available  on  the  web,  but  as  with  most  shareware  products 
their  functionality  and  reliability  is  questionable  since 
there  is  no  commercial  or  technical  rationale  for  the 
developer  to  maintain  the  product . 

JavaScript  was  used  as  the  scripting  code  to  enable  the 
Microsoft  XML  Parser  (MSXML)  and  invoked  the  DOM  APIs.  The 
JavaScript  was  used  to  develop  the  code  necessary  to  inport 
the  particular  database  XML  documents  into  Internet  Explorer 
5.0,  to  parse  that  XML  document  into  a  DOM  node  tree,  to 
analyze  that  DOM  node  tree  for  a  given  search  key,  and  to 
output  results  of  that  search.  The  script  code  developed 
for  the  analysis  process  used  in  this  research  was  adapted 
from  code  found  in  the  book  "XML  IE5"  [XMLIE99]  .  The  code 
was  extensively  modified  to  support  this  research  effort's 
need  to  execute  an  efficient  search  and  manipulation  of  the 
XML  documents .  The  code  used  to  output  the  located  portions 
of  the  XML  document  is  relatively  unchanged  from  the  code  in 
the  book.  It  provides  the  capability  to  import  the  products 
of  the  analysis  into  this  thesis. 
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3 .  Process  Description  Synopsis 

To  facilitate  comprehension  of  the  process,  each  step 
in  the  process  will  be  examined  in  detail  by  stepping 
through  the  JavaScript  code  developed  to  execute  the 
analysis.  The  following  is  a  quick  overview  of  the  process: 

1-  Parsing  the  XML  Document:  The  XML  document  is  parsed 
into  a  DOM  node  tree. 

2.  Node  Tree  Search:  Using  DOM  APIs  the  node  tree  is 
searched  for  desired  elements.  A  node  list  is 
developed  that  contains  all  nodes  that  match  the 
desired  search  key. 

3.  XML  Fragment  Build:  An  XML  fragment  is  built  by  deep 
cloning  the  individually  located  nodes.  This 
cloning  produces  copies  of  the  located  node  and  all 
of  its  children.  The  cloned  node  is  attached  to  the 
fragment.  The  fragment  is  complete  when  all  located 
nodes  (and  children)  have  been  attached. 

4.  Fragment  Decomposition:  The  analysis  process 
concludes  when  the  built  XML  fragment  is  broken  down 
into  the  individual  nodes,  converted  to  text 
outputs,  and  displayed. 


4.  Analysis  Process  Description 

This  process  description  will  examine  key  portions  of 
the  JavaScript  and  DOM  APIs  invoked  to  examine  the  XML 
document.  The  specific  functions  of  the  DOM  APIs  will  be 
emphasized  where  it  facilitates  the  search  and  manipulation 
of  the  document.  The  HTML  code  used  as  part  of  this 
analysis  will  be  described  when  it  impacts  the  involving  of 
the  DOM  APIs. 
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The  complete  code  with  extensive  comments  can  be  found 
in  Appendix  E.  Through  the  comment  lines  the  code  has  been 
divided  into  distinct  sections.  More  critical  sections  like 
the  ones  involving  the  DOM  APIs  will  be  described  in  detail. 
Other  sections  that  are  only  required  to  support  the 
execution  of  the  code  (e.g.,  the  HTML  code)  will  be  briefly 
described. 


a)  XML  Document  Import 

This  section  contains  the  initial  portion  of  the 
HTML  Head.  As  discussed  earlier,  HTML  is  used  to  support 
the  JavaScript  execution  of  the  XML  parser  and  DOM  APIs. 

<XML  ID="doinSearchList"  SRC="YyYY.xml"></XML> 

This  line  informs  IE5.0  to  invoke  its  built-in  XML 
parser.  The  IE5.0  used  in  this  research  project  is  an  early 
version  of  the  XML  parser.  If  a  later  version  of  IE  is  used 
to  execute  this  code,  this  line  may  have  to  be  changed  to 
invoke  the  later  version  of  XML  parser  (i.e.,  MSXML2, 
MSXML3,  etc.)  Examples  of  how  to  invoke  these  later 
versions  of  MSXML  can  be  found  in  Professional  XML  Databases 
[XMDBOO] . 

This  same  line  also  instructs  IE5.0  what  XML  file 
to  import.  Each  time  a  different  XML  document  needs  to  be 
examined  the  "YYYY"  will  have  to  be  changed  to  the  name  of 
that  XML  document .  The  best  way  to  modify  this  code  is  to 
use  the  Notepad  Application  found  on  most  personal  computer 
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platforms.  When  the  HTML  code  is  modified,  be  sure  to  save 
it  as  a  text  file  with  an  HTML  extension.  The  XML  document 
that  is  to  be  parsed  must  be  located  in  the  same  folder  as 
the  HTML  file. 

The  last  line  of  this  section  instructs  IE5.0  that 
JavaScript  will  follow. 

b)  XML  Parsing 

This  section  supports  the  parsing  of  the  XML 
document  into  the  DOM  node  tree  and  to  raise  any  parsing 
error  conditions  if  the  parsing  was  unsuccessful . 

objXMLData  =  docxjment  .all  [ 'domSearchList' ]  ; 

This  line  executes  the  parsing  of  the  XML 
document.  The  remainder  of  the  code  checks  for  and  outputs 
any  parsing  errors.  The  "parseError"  API  is  an  extension 
specifically  by  Microsoft  to  support  Internet 
Explorer.  It  is  not  part  of  the  W3C  DOM  Recommendations. 
It  was  included  because  it  was  simple  to  import  as  is  from 
the  original  code  and  proved  beneficial  when  parsing  the  XML 
documents.  It  identified  several  format /structure  errors  in 
the  XML  documents.  This  was  the  only  Microsoft  IE  specific 
DOM  APIs  employed  in  this  code.  All  other  DOM  APIs  used  are 
included  as  part  of  the  W3C  DOM  Level  Recommendation  1.0. 
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c)  HTML  Search  Function  Call 

The  single  line  contained  in  this  section  calls 
the  " searchDocument "  function  in  the  following  section.  It 
also  returns  the  assembled  strNodes  variable  that  contains 
the  parsed  XML  fragment  that  will  be  described  in  a  later 
section. 

The  searchDocument  function  sends  two  sets  of  data 
to  the  function.  First  is  the  DOM  node  tree  to  be  examined. 
The  second  is  the  search  key  to  be  matched  as  the  DOM  node 
tree  is  searched.  The  search  key  should  be  the  same  as  was 
discovered  in  the  Entity/Attribute  Analysis  and  Conparison 
Section.  The  search  key  will  have  to  be  changed  every  time 
a  different  element  needs  to  be  located  in  the  DOM  node 
tree.  It's  best  to  the  Notepad  Application  to  change  the 
search  key.  This  search  function  is  case  sensitive  so  the 
search  key  must  be  input  exactly  as  was  found  in  the 
Entity/Attribute  Analysis  and  Comparison.  Also,  the 
quotation  marks  must  be  used  with  the  search  key.  The 
following  example  is  taken  from  the  code  in  Appendix  E: 
divResults . innerHTML  s  searchDocument (objXMLData,  "TARGET- 

ENGAGEMENT  -ASSESS"  )  ; 

d)  DOM  Tree  Search 

This  section,  along  with  the  following  four 
sections  describes  the  searchDocument  function.  This 
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function  is  the  primary  function  developed  for  this  research 
It  executes  the  search  for  the  common  elements, 
extraction  of  the  common  elements,  and  the  calling  of  the 
functions  required  to  build  the  output  of  those  extracted 
elements . 

This  section  establishes  all  the  variables  used  in 
this  function.  The  key  variable  "objFrag"  is  created  as  an 
XML  fragment.  It  is  considered  a  fragment  since  it  is  not  a 
well  formed/valid  XML  document.  It  will  contain  only  a  root 
element  and  added  elements.  This  fragment  is  a  holder  of 
the  common  elements  located  during  the  DOM  node  tree  search. 
llstNodes  s!  theRoot.getElementsByTagNaitie(searchKey)  ; 

The  line  above  calls  the  DOM  API  to  search  the  DOM 
node  tree  for  all  the  elements  that  match  the  "searchKey". 
It  stores  the  located  common  elements  in  a  node  list.  For 
example,  if  the  DOM  node  tree  contained  4  separate 
occurrences  of  the  element  <CAR>,  the 

getElementsByTagName ( "CAR" )  would  return  a  node  list 
containing  those  four  specific  <CAR>  nodes. 

The  use  of  the  getElementsByTagName  API  will  be 
highly  beneficial  when  searching  extremely  large  DOM  node 
trees  like  those  that  would  be  built  from  JCDB  and  MIDB. 
The  getElementsByTagName  is  only  called  once  during  the 
entire  analysis  process.  Only  having  to  search  the  DOM  node 
tree  once  makes  this  developed  search  process  very 
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efficient.  The  resulting  node  list  used  from  this  point  on 
contains  the  specific  information  of  the  located  elements 
(e.g.,  location  in  the  tree). 

e)  Notification  of  Found  Elements 

This  section  examines  the  listNodes  variable 
containing  the  built  node  list  to  see  if  it  contains  any- 
matched  nodes.  The  "listNodes. length"  returns  the  number  of 

nodes  in  listNodes.  If  the  listNodes . length  is  greater  than 
0,  an  alert  window  is  opened  displaying  how  many  common 
elements  were  found.  If  listNodes . length  equals  0,  then  two 
alert  windows  are  opened  providing  additional  guidance. 
Even  if  the  listNodes .  length  is  equal  to  0,  the  code 
continues  to  execute  until  complete.  Again  this  does  not 
impact  execution  time  since  all  subsequent  executions 
triggers  loops  that  use  the  listNodes .  length  as  the  upper 
limit  of  the  loop.  So  when  listNodes . length  is  equal  to  0, 
the  loops  do  not  execute. 

f)  Extracting'  Found  Nodes/Building  XML  Fragment 

This  executes  a  loop  to  extract  the  individual 
nodes  from  the  node  list  and  adds  them  to  the  previously 
created  XML  fragment.  The  nodes  listed  in  listNodes  are 
numbered  starting  with  zero.  So  listNodes (0)  identifies  the 
first  located  node,  listNodes (1)  identifies  the  second  and 
so  on. 
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Each  time  the  loop  executes  for  1=0  through  1= 
li®^Nodes .  length  the  following  line  is  used  to  take  the 
found  node  and  clone  it : 

objNode  =  foundNode . cloneNode (true) ; 

As  described  earlier,  the  cloneNode (true)  API 
makes  an  exact  duplicate  of  the  node  and  of  all  the 
descendant  nodes.  For  the  purposes  of  this  research  effort, 
critical  to  extract  these  descendants  since  they  will 
be  an  important  part  of  the  database  to  database  comparison, 
obj Frag. appendChild (objNode) ; 

The  line  above  attaches  the  cloned  node  (and  its 
descendants)  to  the  XML  fragment. 

The  loop  continues  to  execute  until  all  the  nodes 
contained  in  listNodes  have  been  cloned  and  added  to  the  XML 
fragment.  An  alert  window  is  opened  to  display  the  entire 
XML  fragment.  The  person  conducting  the  analysis  can 
quickly  scan  the  alert  window  to  determine  if  the  desired 
information  was  found  in  the  fragment.  If  the  alert  window 
is  large  the  "OK”  button  may  be  off  the  screen.  If  this 
happens  simply  hit  "ENTER"  key  to  close  the  window. 

g)  Building'  the  Output 

This  section  executes  the  same  loop  as  before  to 
sgain  extract  the  nodes  in  listNodes.  Each  execution  of  the 
loop  calls  the  "showChildNodes"  Function  sending  the  node 
from  listNodes.  This  function  was  modified  from  code  found 


82 


in  the  XML  IE5  book  [XMLIE99]  .  The  showChildNodes  F^Inction 
returns  a  text  output  containing  the  parsed  details  of  the 
node  sent  during  the  function  call.  This  text  output  is 
appended  to  the  strNodes  variable. 

The  searchDocument  Function  is  completed  when  the 
listNodes  loop  has  finished.  The  strNodes  variable 
containing  the  assembled  text  output  of  the  all  the  located 

I 

nodes  is  returned  for  display. 

b)  Parsing  Node  for  Output 

This  section  contains  the  definition  of  variables 
and  the  assembly  of  the  information  on  the  nodes  sent  to  the 
showChildNodes  Function.  The  strNodes  variable  is 
continuously  appended  with  information  on  the  node.  The 


following  information 

is  appended  to  strNodes: 

API  or 

Action 

Fvinction  Call 

get Indent (intLevel) 

A  function  call  to  improve  readability 

of  output.  Will  be  describe  in  more 

detail  in  get Indent  Function  Section. 

objNode . nodeName 

Returns  name  of  objNode. 

getNodeType (objNode . 

nodeType ) 

obj Node . nodeType  returns  a  number 

between  1  and  12 .  These  values  are 

predefined  values  that  are  associated 

with  the  individual  node  types  that 
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can  be  found  in  a  DOM  Node  Tree  (see 

figure  4)  .  The  getNodeType  fiinction 

is  called  sending  node  type  integer. 

See  the  getNodeType  Function 

description. 

obj  Node . nodeValue 

uReturns  a  text  equivalent  of  the  value 

contained  in  the  node.  If  no  value  if 

found,  null  will  be  returned. 

i)  Output  Attribute  Node  Information 

This  section  returns  any  attribute  infoinnation 
related  to  this  node.  Nothing  will  be  added  to  strNodes  if 
there  are  no  attributes  associated  with  this  node. 

Invoking  the  obj Node . attributes  API  develops  an 
attribute  list  containing  all  the  attributes  associated  with 
the  objNode.  This  list,  called  the  NaitedNodeMap,  functions 
just  as  the  node  list. 

The  objAttrList  (the  attribute  list)  is  first 
checked  to  see  if  it  contains  any  attributes.  If 
objAttrList  is  not  equal  to  "null"  the  function  continues  to 
parse  the  attributes.  A  loop  is  then  called  to  parse  all  of 
the  attributes  contained  in  the  attribute  list.  The  same 
DOM  APIs  used  to  examine  the  nodes  in  the  node  list  are  used 
to  examine  the  attributes  in  the  attribute  list.  Each  loop 
execution  appends  the  attribute  information  to  the  strNodes 


84 


variable.  Review  of  the  JavaScript  code  in  Appendix  E  is 
reccotnmended  to  see  the  similarities. 

j)  showChildNodes  Function  Called  Again 
When  the  nodes  were  originally  cloned,  their 
descendant  nodes  were  also  cloned.  This  section  examines 
the  node  to  determine  if  it  contains  any  children  nodes.  If 
so,  the  showChildNodes  function  is  called  again  to  get 
information  on  that  child  node.  If  that  child  node  contains 
its  own  children  nodes  the  showChildNodes  function  will  be 
called  again  to  get  their  information.  This  is  what  is 
called  a  "recursive"  function  call.  This  basically  means 
that  a  function  calls  itself.  In  the  case  of  this  analysis, 
the  recursive  function  calls  will  continue  until  all  the 
descendant  nodes  of  the  original  node  have  been  located  and 
their  parsed  node  information  has  been  appended  to  the 
strNodes  variable. 

k)  getNodeType  Function 

The  getNodeType  Function  returns  a  text  output 
describing  the  type  node  being  examined.  The  specific 
output  is  based  on  the  integer  identified  by  the 
objNode.nodeType  and  objAttrList (intAttr) .nodeType  DOM  API 
calls . 
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1)  getindent  Function 

This  section  contains  the  getindent  Function  that 
is  used  to  insert  indents  into  the  strNodes  variable  to 
improve  readability  of  the  output.  Each  time  the  showChild 
Function  is  called,  the  indentation  is  increased.  This 
makes  it  easier  to  distinguish  the  parent  nodes  from  the 
children  nodes . 

This  section  also  completes  the  JavaScript  used  to 
execute  the  analysis  of  the  XML  document.  The  remainder  of 
the  sections  describe  the  remaining  HTML  code  required  to 
execute  the  analysis . 

m)  parseXML  Function  Call 

This  section  calls  the  parseXML  Function  described 
previously.  It  also  calls  the  searchDocument  Function  and 
displays  the  completed  strNodes  variable. 

n)  XML  Documant  Button 

This  HTML  code  displays  a  button  that  when 
selected  displays  a  separate  page  containing  the  XML 
document  that  was  analyzed.  This  code  was  left  in  because 
it  helped  during  code  debugging.  It  is  strongly  recommended 
that  this  button  function  be  disabled  as  described  in  the 
comment  line  of  the  code  when  analyzing  extremely  large  XML 
documents,  like  those  built  from  JCDB  and  MIDB. 
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5. 


Summary  of  Analysis  Process 


The  code  just  described  provides  a  standardized  search 
and  manipulation  process  that  can  be  used  on  any  XML 
document.  This  code  provides  several  benefits: 

One  benefit  of  using  a  standardized  analysis  process  is 
that  the  outputs  are  standardized.  This  simplifies  the 
process  of  comparing  the  located  nodes  from  heterogeneous 
databases . 

This  analysis  process  only  searches  the  DOM  node  tree 
once.  The  node  list  built  during  the  initial  search  is  used 
from  that  point  on  to  extract  the  located  nodes.  This 
provides  a  timesavings  when  searching  extremely  large  DOM 
node  trees  built  from  databases  like  JCDB  and  MIDB  are 
analyzed. 

This  process  extracts  small,  comparable  outputs  from 
large  databases.  This  eases  the  efforts  to  compare  the 
potentially  common  elements. 

F.  JCDB  AND  MIDB  VIEW  ANALYSIS 

1.  Analysis  Coirqponent  Review 

The  following  describes  all  the  components  developed  to 
support  this  analysis : 

Entity  Relationship  Diagrams:  These  diagrams  were 
developed  for  the  selected  views  of  the  JCDB  and  MIDB. 
These  particular  views  were  chosen  for  their  inherent 
commonality  that  would  help  facilitate  the  description  of 
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this  process.  These  views  focused  on  the  Target  Engagement 
and  Target  Engagement  Assessments  domains. 

The  particular  view  of  the  JCDB  Entity  Relationship 
Diagram  was  extracted  from  the  provided  JCDB  Entity 
Relationship  Diagram.  The  MIDB  Entity  Relationship  Diagram 
was  unavailable  for  this  research  effort .  As  a  result  the 
entity  relationship  diagram  of  the  selected  MIDB  View  was 
built  manually  from  the  relationships  identified  in  the  MIDB 
Data  Dictionary. 

XML  Documents:  The  XML  documents  for  the  JCDB  and  MIDB 
Views  had  to  be  built  manually  because  the  databases  were 
not  available  for  this  research  effort.  As  described  in 
Section  IV. C,  different  automated  method  are  available  and 
should  be  used  whenever  possible  when  trying  to  convert 
sxtremely  large  database.  This  is  another  reason  specific 
views  of  the  databases  were  chosen  for  the  research  effort. 
These  smaller  views  supported  the  manual  development  of  the 
example. 

The  XML  documents  were  developed  in  a  manner  that 
supported  description  of  the  analysis  process.  Also  these 
XML  documents  were  developed  without  DTDs  or  Schemas.  The 
developed  analysis  process  does  not  require  the  DTDs  or 
Schemas .  For  those  who  are  concerned  about  the  lack  of  DTDs 
or  schemas,  this  analysis  process  does  not  preclude  the  use 
of  the  DTDs  or  Schemas . 
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Search  Keys:  As  described  earlier,  the  search  keys 
would  be  provided  as  products  of  the  Entity/Attribute 
Analysis  and  Comparison  process  described  in  Mr.  Hamza 
Zobair's  Thesis:  "An  Approach  for  Matching  Corresponding 
Attributes  in  Legacy  Heterogeneous  DoD  Databases".  Due  to 
the  concurrency  of  Hamza  Zobair's  research  and  mine,  his 
described  analysis  process  was  not  used  as  part  of  this 
research  effort.  Instead  search  keys  were  manually  selected 
based  on  their  inherent  similarities.  The  search  key 
selected  for  the  JCDB  View  was  "TARGET  ASSESSMENT".  The 
search  key  selected  for  the  MIDB  View  was  "TGT_DTL_ASSESS" . 

2.  JCDB  Analysis 

The  first  step  in  the  JCDB  analysis  is  to  insert  the 
name  of  the  XML  document  to  be  analyzed  and  the  given  search 
key.  Using  Internet  Explorer,  open  the  HTML  file  containing 
the  analysis  code.  To  execute  the  analyses  simply  click  the 
"GO"  button  at  the  right  side  of  the  address  bar. 

The  first  alert  window  to  open  displays  how  many 
"TARGET  ASSESSMENT"  nodes  were  located  in  the  JCDB  DOM  node 


Figure  6:  Found  Node  Alert  Window 
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tree.  Figure  6  shows  how  many  TARGET  ASSESSMENT  were  nodes 
located  in  the  JCDB  Node  Tree. 

Click  the  "OK"  button  or  hit  the  "Enter"  key  and  the 
second  alert  window  opens  displaying  the  located  nodes  and 
all  their  descendant  nodes.  The  Figure  7  shows  that  some  of 
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Figure  7:  Snapshot  of  Located  Nodes 
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located  information  can  be  quickly  reviewed  to  determine  if 
its  the  type  of  information  desired. 

Note  that  some  of  the  information  is  located  off  the 
screen.  This  is  not  important  since  a  more  thorough  output 
will  follow.  Since  the  "OK"  button  is  located  off  the 
bottom  of  the  screen  the  "Enter"  key  will  have  to  be  hit  to 
close  the  window. 

The  nodes  displayed  in  the  previous  alert  window  are 
then  parsed  into  the  final  standardized  output  and  displayed 
in  the  Internet  Explorer  window.  This  output  can  be  printed 
or  copied  into  other  software  products  for  the  following 
comparison.  Due  to  its  size,  the  output  from  the  JCDB 
analysis  is  included  in  Appendix  F.  This  completes  the 
process  of  searching  the  JCDB  for  specified  nodes, 

3 .  MIDB  Analysis 

The  exact  same  analysis  process  is  used  to  analyze  the 
MIDB  View.  The  only  variation  required  is  to  change  the 
name  of  the  XML  document  to  be  analyzed  and  changing  the 
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search  key  to  "TGT_DTL_ASSESS" .  The  corresponding  alert 
windows  are  shown  in  the  following  two  figures  and  the  final 
output  is  included  in  Appendix  G. 


G.  FINAL  STEP  -  COMPARISON  OF  ANALYSIS  RESULTS 

The  objective  of  the  previous  analyses  was  to  build  a 
series  of  comparable  outputs  that  a  SME  could  compare  to 
determine  if  the  located  information  is  common/ similar.  As 
can  be  seen  in  the  outputs  contained  in  Appendix  F  and 
Appendix  G,  even  though  the  search  keys  used  were  similar, 
the  located  data  looks  quite  different  in  terms  of  content 
and  hierarchical  relationships.  This  should  not  be 
unexpected  when  comparing  heterogeneous  databases.  Taking 
into  account  that  each  database  was  originally  developed  to 
support  a  specific  system-use  these  outputs  should  probably 
look  different. 

The  differences  in  the  analysis  output  is  the  very 
reason  the  analysis  process  was  developed.  It  provides  an 
alternative  to  the  very  complicated  task  comparing  the  very 
Isrge  databases.  This  analysis  process  has  winnowed  down 
these  very  large  databases  into  two  comparable  XML  based 
outputs  that  SMEs  should  be  able  to  ascertain  whether  they 
are  common . 

The  comparison  process  consists  of  providing  the  SME(s) 
with  the  results  of  the  analysis.  The  SME(s)  can  review 
individual  components  (i.e.,  elements,  attributes,  etc.)  of 
each  output  along  with  the  associated  hierarchical 
relationships  of  those  components.  The  SME  can  then  compare 
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the  two  outputs  to  determine  if  they  represent  the  same 
information. 

Exactly  how  the  outputs  are  compared  should  be  left  up 
to  the  individual  SMEs.  Different  SMEs  would  probably 
emphasize  different  portions  of  the  outputs  during  their 
comparisons . 

1 .  Con^arison  Exan^le 

Here  is  an  example  of  how  an  SME  might  coitpare  the  two 
extracted  and  decomposed  outputs.  Figure  10  contains  a 
portion  of  the  JCDB  output  that  shows  a  simple  overlay 


tMOET-ENGAGEMENT-ASSESS  Type:  ELEMENT  m  Value:  null 


BKGMENT  _ASSES  INDX  Type:  ATTRIBUTE  (2)  Value:  1 


[E|<rGAGE_END_DTTM  Type:  ELEMENT  (1)  Value:  null 
^extTvpe:  TEXT  Gl  Value:  010625100000 


IlLGT  DISPO_CD  Type:  ELEMENT  (1)  Value:  null 


|LABEL  Type:  ELEMENT  (1)  Value:  null 

I  #text  Type:  TEXT  (3)  Value:  6 _ 

:kGAGE_DMG_PERCNT  Type:  ELEMENT  (1)  Value:  null 
ijttext  Type:  TEXT  (3)  Value:  90 


|N|(JM_OF_CASUALITIES  Type:  ELEMENT  (1)  Value:  null 
j^ext  Type:  TEXT  (3)  Value:  15 


CODE  Type:  ATTRIBUTE  (2)  Value:  1 


A 


IffiCORD  STATUS  Type:  ELEMENT  (1)  Value:  null 


CODE  Type:  ATTRIBUTE  (2^  Value:  A 


RECORD_STATUS_DTTM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  010625074500 _ 


V 


LABEL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  12 


hm  Descendante^^^^^^ 


Figure  10:  Portion  of  JCDB  Output 
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method  to  show  the  hierarchical  relationships  and  the 
different  nodes  that  make  up  the  output. 

The  SME  could  easily  do  this  with  all  extracted  outputs 
or  the  HTML  code  could  be  revised  to  show  these 
relationships  overlays.  The  goal  would  be  to  examine  the 
individual  nodes  with  regards  to  where  they  fit  in  the 
hierarchy  and  the  type  of  information  they  contain. 

Similarities  between  the  outputs  would  have  to  be 
examined  as  well  as  the  nodes  that  do  not  look  similar.  The 
goal  would  be  to  equate  the  two  outputs  to  determine  if  the 
similar  aspects  of  the  two  outputs  outweigh  the  non-similar 


JCDB  Output  Portion 

TARGET>ENGAGEMENT-ASSES$  Type:  ELEMENT  fl)  V^ue:  nuU 

IeNGMENT  asses  1M)X  Type.  ATnUBUTE  (2)  Value:  iN - 

ENGAGE  END_DTTM  Type:  ELEMENT  (1)  Value;  null 
#text  Type:  TEXT  (3)  Value:  010625100000 
TRGTJIISPO^CD  Type:  ELEMENT  (1)  Value:  null 
CODE  Type:  ATTRIBUTE  (2)  Value:  1 
LABEL  Type:  ELEMENT  (1)  Value:  null 

Typf-  TFXr  C^y  Val....-  fi 


MIPS  Output  Portion 

Similar'^  TGT  DTL  assess  Tvdc:  elements  Value:  nuM _ 

- - HrGT_DTL_ASSESS  SK  Type:  ATTRIBUTE  (2)  Value:  24373] 

ASSESS  TYPE  Type:  ELEMENT  (1)  Value:  nnU 
#text  Type:  TEXT  (3)  Value:  BDA 
CLASS^LVL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  U 


[ENGAGE  DMG  FERCNTType;  ELEMENT  (1)  Value:  nul 
Jtext  Ivpc;  nm  (3)  Value:  9Q 


NUM_OF_CASUALrnES  Type:  ELEMENT  (1)  Value:  uuU 
#text  Type:  TEXT  f3)  Value:  IS _ 


RECORD  STATUS  Type:  ELEMENT  (1)  Value:  null 
ilQPEJype:  ,ATTRIBVTE  (1)  Value:  A 


|RECORD_STATUS_DTTM  Type:  ELEMENT  (1)  Value;  niH 
#text  Type:  TEXT  (3)  Value:  010625074500 _ 


LABEL  Type:  ELEMENT  (1)  Value:  nuU 
#text  Type:  TEXT  (3)  Value;  12 
PERCEPTION  Type;  ELEMENT  (1)  Value;  nuD 
PERCEP  REF  INDX  Type:  ATTRIBUTE  (2)  Value:  8659 
PERCEP_INPUT_ID  Type:  ELEMENT  (I)  Value:  nuU 
#text  Type:  TEXT  (3)  Value;  48394 
RPRTlNG_ORG  Type;  ELEMENT  (1)  Value:  null 
RPRUNG  ORG_ID  Type;  ATTRIBUTE  (2)  Value:  34732 
RPRTTNG^ORG^lNPUTTypc:  ELEMENT  (1)  Value;  null 
#text  Type:  TE^  (3^  Value:  29483 


|PERCEP_REPRTJ)TTM  Type:  ELEMENT  (1)  Value:  nuU 
#text  Type:  TEXT  (3)  Value:  010625101500 _ 


DATETIME^CREATED  Type:  ELEMENT  (1)  Value:  nuD 
jftext  Type:  TEXTffl  Value:  19650302183212 


DATETIME_LAST_CHG  Type;  ELEMENT  (1)  Value;  nnU 
#textType:  TEXT  (3)  Value:  19650302192354 


DOMAIN  LVL  Type:  ELEMENT  (1)  Value:  nnll 
#text  Type:  TEXT  (3)  Value:  CO 
EVAL  Type:  ELEMENT  (1)  Value;  null 
#text  Type:  TEXT  (3)  Value:  S 


|rECORD_STATUS  Type:  ELEMENT  (1)  Value;  nnll 
#text  Type:  TEXT  (3)  Value:  A 


RECUP_INTRVL  Type;  ELEMENT  (1)  Value:  noU 
#text  Type;  TEXT  Value:  1000 


|RECUP^INTRVL_MAX  Type:  ELEMENT  (1)  Value:  i 
#text  Type:  TEXT  (3)  Value:  1500 


RECUF_INTRVLJJM  Type;  ELEMENT  (1)  Value;  i 
#text  Type:  TEXT  (3)  Value:  14DAY 


RELEASE^MARK  Type;  ELEMENT  (1)  Value:  null 
mtxt  Type:  TEXT  (3)  Value:  BZ 
RES  PROD  Type:  ELEMENT  (1)  Value;  nnU 
#text  Type:  TEXT  (3)  Value:  Z 
REVIEW_DATE  Type:  ELEMENT  (I)  Value:  nnU 
#text  Type;  TEXT  (3)  Value:  19650320120000 


Figure  1 1 :  Hierarchy  and  Node  Content  Comparison 
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aspects.  As  Figure  11  shows,  the  SME  is  still  faced  with  a 
challenge  to  determine  if  the  outputs  are  common. 

Recalling  that  these  two  outputs  were  built  from  the 
previously  identified  common  "search  keys"  it  is  interesting 
that  when  the  database  components  and  hierarchical 
relationships  are  extracted,  the  commonality  comparison 
becomes  a  much  more  complex  task.  In  fact,  these  extracted 
outputs  may  show  that  they  represent  very  different  types  of 
information  even  though  they  were  originally  raised  as 
candidates  for  commonality.  In  fact,  it  is  the 
relationships  between  the  individual  elements  that  present 
the  SME  with  the  additional  information  necessary  to  execute 
the  comparisons. 

The  advantage  of  this  developed  analysis  and  comparison 
method  is  the  availability  of  useable  information.  All  the 
necessary  detail  of  the  hierarchical  node  relationships  and 
individual  node  content  is  extracted  and  decomposed  into  a 
series  of  the  outputs  that  can  be  examined  by  the  SME.  It 
simplifies  the  SME's  comparison  tasks  considerably.  It  also 
improves  the  thoroughness  of  the  cotrparisons .  Recalling 
that  the  original  materials  available  were  the  databases, 
the  data  dictionaries,  and  the  entity  relationship  diagrams. 
The  database,  being  stored  in  some  unique  DBMS  format,  would 
be  unreadable  without  the  database  software.  The  data 
dictionary  and  entity  relationship  diagrams  are  large, 
complex,  and  usually  difficult  to  read. 
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Using  this  analysis  and  comparison  method,  the  SME  is 
now  presented  with  easily  readable  outputs  containing  the 
desired  infoirmation  for  comparison.  If  a  specific  term  is 
not  inherently  understandable  the  specific  portion  of  the 
data  dictionary  and/or  entity  diagrams  can  be  consulted  for 
detail . 

2 .  Con^arison  Summary 

This  completes  the  analysis  and  comparison  process 
developed  in  this  research  effort.  The  goal  of  locating  and 
providing  potential  common  data  from  heterogeneous  databases 
has  been  achieved.  The  data  provided  is  in  the  context  of 
both  detailed  information  of  the  individual  components  and 
the  hierarchical  relationships  of  those  components.  Only  by 
examining  both  the  components  and  hierarchical  relationships 
contained  in  the  databases  can  the  database  analysis  and 
comparison  truly  useful . 

Hopefully,  using  this  analysis  and  comparison  method, 
the  SMEs  now  can  better  focus  and  simplify  their  comparison 
efforts. 

H.  CHAPTER  CONCLUSION 

The  database  analysis  and  comparison  process  described 
in  this  chapter  is  represented  in  Figure  12 .  The  specific 
sections  describing  each  individual  step  is  indicated  by  the 
section  number  included  in  each  step.  The  following 
provides  a  brief  summary  of  each  step: 
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Database  Review 
(IV.B) 


JCDB 


MIDB 


XML  Conversion 


JCDB/ 

XML  Doc 

Search  Key 
Determination 

_ gvp) 


JCDB 

Search  Kevs 


XML  Parse  into  DOM  Tree 
P  (IV.E.4.a.c)  9, 

'Wj 

CD 


Search  Key 
Determination 

(Tv.m 


Search/Extract  based  on  Search  Key 

av.E.4.<i-.)  tf  m 


-CZ] 

ku 


MDDB 
Search  Keys 


SME  Comparison 
(IV.G  &  Figures  10  &  11) 


JCDB 

Output 


MIDB 

Output 


Figure  12:  Analysis  and  Comparison  Process 


1  •  Database  Review  Simimary 

This  step  focuses  on  the  manual  examination  of  each 
database  to  be  analyzed  and  compared.  The  siibsequent 
database  conparisons  will  be  of  more  value  if  each  database 
contains  the  same  type  of  information. 

2 .  Database  Conversion  to  XML  Summary 

This  step  focuses  on  the  conversion  of  the  databases 
into  XML  documents.  The  recommended  approach  is  to  utilize 
the  COTS  based  database  to  XML  translators  contained  in  most 
commercial  DBMS.  This  provides  an  automated  method  to 
execute  this  task.  Using  automated  means  to  complete  this 


98 


task  is  important  since  the  large  databases,  like  JCDB  and 
MIDB,  will  translate  into  extremely  large  XML  documents. 

An  alternative  method  that  can  be  used  is  to  utilize 
the  ODBC  APIs  built  into  most  DBMSs  to  manipulate  the 
databases  into  an  ODBC  structure.  This  structure  can  then 
be  converted  to  XML  by  using  the  0DBC2XML  translator 
shareware . 

3.  Entity/At  tribute  Analysis  and  Cos^arison  Sxumiary 

This  step  in  the  process  focuses  on  locating  specific 
common  entities  and  attributes  between  multiple  databases. 
This  provides  the  search  keys  for  the  subsequent 
hierarchical  analyses  of  the  XML  documents.  This  process  is 
the  subject  of  Mr.  Hamza  Zobair's  Thesis  entitled:  "An 
Approach  for  Matching  Corresponding  Attributes  in  Legacy 
Heterogeneous  DoD  Databases"  [HZOl] . 

4 .  Hierarchical  Examination  Summary 

This  step  is  comprised  of  steps  that  parse  the  XML 
documents  into  DOM  node  trees,  searches  those  trees  using 
specified  search  keys,  and  extracts  desired  nodes  and 
descendant  nodes.  This  automated  process,  developed  for 
this  research  effort,  utilizes  IE  and  its  built-in  XML 
parser  to  parse  the  XML  document.  Then  DOM  APIs  are  invoked 
using  JavaScript  to  execute  the  DOM  node  tree  search  and 
extract  the  located  nodes  and  descendant  nodes.  The 
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following  table  contains  each  of  the  DOM  APIs  and  functions 
used  to  execute  this  search  and  extraction: 


DOM  API  or  Function; 

Action: 

getElementsByTagName ( 

Builds  a  node  list  containing  each 

searchKey) 

tag  that  matches  the  search  key. 

length 

Returns  an  integer  representing  the 

number  of  nodes  contained  in  list. 

cloneNode (deep) 

Returns  a  duplicate  of  node.  Deep  is 

a  boolean  value.  If  false,  returns 

node.  If  true,  the  node  and  entire 

subtree  under  the  node  is  retuimed. 

appendChi Id ( ob j  Node ) 

Appends  node  to  existing  node. 

showChildNodes 

A  tunction  call  to  examine  the  child 

nodes  of  the  current  node. 

get Indent (int Level) 

A  function  call  to  improve 

readability  of  output . 

nodeName 

Returns  name  of  objNode. 

getNodeType (objNode . n 

Ob j Node . nodeType  returns  a  number 

odeType) 

between  1  and  12 . 

nodeValue 

Returns  a  text  equivalent  of  the 

value  contained  in  the  node.  If  no 

value  if  found,  null  will  be 

returned . 

attributes 

Generates  a  list  of  attributes 

contained  in  node. 
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parseError 

An  IE  unique  API  that  identifies  any 

errors  during  XML  parsing. 

5.  Con^arison  of  Analysis  Results  Summary 

This  step  presents  the  extracted  data  to  be  compared  to 
the  SME.  As  can  be  seen  in  Section  IV. G  and  Figures  10  and 
11,  the  extracted  portions  can  look  quite  different.  Only  a 
SME  would  be  able  to  determine  if  the  extracted  portions  are 
similar.  When  taking  into  account  the  hierarchical 
relationships  contained  in  these  databases,  this  comparison 
can  be  quite  complex.  During  this  research  effort  no 
automated  methods  to  accomplish  this  task  could  be  found 
that  might  aid  the  SME  in  this  task. 

The  benefit  this  research  provides  is  that  it 
simplifies  the  SME's  comparison  task  by  providing  only  the 
desired  information  to  be  compared  in  an  easily  readable 
format.  The  SME's  alternative  would  be  to  conduct 
exhaustive  reviews  of  the  databases,  data  dictionaries,  and 
entity-relationship  diagrams. 

6 .  Research  Limitations 

The  analysis  and  comparison  process  described  contained 
in  this  thesis  does  have  some  limitations; 

a.)  Level  of  Detail 

The  effort  to  develop  databases  to  the  same  "level 
of  detail"  could  be  a  complicated  task  if  the  databases  to 
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be  compared  are  significantly  large  and  different. 
Databases  like  the  ones  discussed  in  this  thesis  are  very 
and  complex.  That  is  why  smaller  views  of  the  JCDB 
and  MIDB  where  used  in  this  thesis  to  describe  the  analysis 
and  comparison  process. 

b)  Size  Growth 

Another  limitation  is  the  growth  associated  with 
the  conversion  of  the  databases  to  XML  documents  and  then  to 
DOM  node  trees.  The  size  of  the  original  databases  are  very 
large  to  start  with.  The  subsequent  conversions  can 
possibly  lead  to  a  100  to  1  growth  in  size.  With  XML  being 
the  focus  of  this  result,  this  problem  cannot  be  avoided. 
Fortunately,  the  rapidly  advancing  state-of-the-art  in 
computer  technology  makes  this  less  of  a  problem  as  time 
goes  on. 

c)  Manual  Comparison  of  Outputs 

The  SMEs  are  required  to  execute  manual 

comparisons  of  the  extracted  portions  of  the  databases.  As 
shown  in  Figures  10  and  11  this  can  present  the  SMEs  with  a 
task  when  considering  the  hierarchical  node 
relationships  and  the  individual  node  contents.  The 
advantage  provided  by  this  process  is  that  all  the  data  to 
be  compared  is  presented  in  a  succinct  and  easy  to  read 


102 


format.  The  SME  will  still  have  to  make  some  hard  decisions 
on  what  is  similar  and  what  is  not . 

An  alternative  to  the  process  described  in  this 
research  effort  is  for  the  SMEs  to  rely  solely  on  the 
databases,  data  dictionaries,  and  entity  relationship 
diagrams.  In  that  case,  the  comparisons  would  probably  take 
days,  or  even  weeks  just  to  locate  a  single  entity  that  is 
comparable  in  terms  of  hierarchy  and  in  content. 

7.  Example  Crosswalk 

To  simplify  the  process  description  provided  in  this 
chapter  the  following  table  is  provided  to  identify  the 
specific  sections  containing  the  individual  step 
descriptions  and  associates  them  to  the  sections  describing 
the  actual  step  execution  on  the  JCDB  and  MIDB  views. 


Process  Step 

JCDB  Execution 

MIDB  Execution 

Level  of  Detail 

IV. B 

IV. B. 2 

IV. B. 3 

XML  Conversion 

IV.  C 

IV. C. 3 

IV. C. 3 

Search  Key  Determ. 

IV. D 

IV. D 

IV. D 

XML  Parse  to  DOM 

IV.E.4.a-c 

IV. F. 2 

IV. F. 3 

Search/Extraction 

IV. F. 2 

IV. F. 3 

IV.E.4.d-n 
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SME  Comparison 

IV. G 

IV.  G 

IV. G 

8.  Commercial  Application  of  Process 

The  XML  parse,  search,  and  extraction  portions  of  the 
described  analysis  and  comparison  process  could  be  a  useful 
commercial  application.  The  code  was  written  in  a  manner 
that  would  allow  it  to  parse  and  analyze  any  XML  document. 
It  uses  specified  search  keys  to  locate,  extract,  and  output 
the  desired  nodes  and  descendant  nodes.  This  code  could 
revised  to  take  those  extracted  nodes  and  import 
them  into  new/different  XML  documents.  This  is  described  in 
greater  detail  in  the  Future  Work  Research  Possibilities 
Section. 

9 .  Putting  This  Research  Into  Practice 

As  described  earlier  in  this  thesis,  this  research  is 
part  of  a  larger  XML-C4I  Database  analysis  research  effort. 
The  products  from  this  research  will  be  incorporated  with 
the  other  research  efforts  into  an  analysis  process  that 
examines  multiple  opportunities  to  use  XML  to  facilitate 
^^n.ipulation  of  C4I  databases  as  a  means  to  support  in^roved 
C4I  interoperability. 
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V. 


CONCLUSION  AND  FINAL  RESEARCH  POSSIBILITIES 


A.  CONCLUSION 

This  thesis  examines  in  detail  how  XML  can  be  employed 
facilitate  the  analysis  and  comparison  of  heterogeneous 
databases.  It  provides  a  decomposition  of  located  similar 
components  that  can  be  compared  to  determine  what  components 
are  common  and  what  components  are  not. 

The  first  sections  of  this  thesis  provides  significant 
detail  on  XML  and  the  current  DoD  C4I  environment.  This 
background  information  provides  the  foundation  upon  which 
this  XML  based  analysis  and  comparison  process  was  designed, 
developed,  executed,  and  described. 

The  original  research  objective  being  examined  in  this 
thesis  was  to  determine  if  an  XML  schema  could  be  defined  to 
support  the  scalability  of  components  from  multiple  legacy 
databases  to  modern  C4I  systems.  This  thesis  successfully 
proves  that  XML  based  schemas  can  be  developed  that  can 
facilitate  this  legacy  to  modern  C4I  migration.  XML 
provided  the  common  basis  upon  which  the  analysis  could  be 
executed  and  the  common  elements  extracted. 

This  thesis  describes  a  new  XML  based  C4I  database 
analysis  and  comparison  method.  It  support  the  first  step 
towards  data  exchange  between  C4I  databases  by  supporting 
the  determination  of  what  parts  of  the  individual  C4I 
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databases  are  similar.  As  a  result,  it  provides  the  means 
to  facilitate  the  interoperability  between  these  different 
C4I  systems  identifying  data  that  may  be  exchanged  by 
individual  databases. 

COTS  products  were  employed  in  the  development  of  the 
analysis  and  comparison  process.  By  utilizing  COTS  an 
additional  benefit  resulting  from  this  method  was  its 
broader  application  beyond  C4I  databases.  This  new  method 
can  be  used  to  analyze  and  compare  any  XML  document. 

Overall,  this  research  effort  was  successful  in 
achieving  its  original  investigation  objectives. 

B.  FUTURE  WORK  RESEARCH  POSSIBILITIES 

Opportunities  for  future  work  in  this  field  are 
extensive.  The  following  are  just  a  few  recommendations: 

Continue  to  refine  the  analysis  and  comparison 
process  developed  in  this  research  effort.  As  the  DOM 
Recommendations  continue  to  be  approved,  a  number  of  new  DOM 
APIs  will  become  available  that  could  be  eiiployed  to  improve 
and  expand  this  XML  based  analysis  and  comparison  process. 

-  Define  in  more  detail  the  Subject  Matter  Expert  (SME) 
comparison  portion  of  the  process.  This  could  include  an 
examination  of  how  to  best  format  the  outputs  from  the  XML 
based  analysis  to  support  the  SME  review  and  comparison. 

-  Investigate  how  the  extracted  common  products  from 
this  XML  based  analysis  and  comparison  could  be  restructured 
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into  a  global  C4I  database.  In  effect  this  process  would 
reverse  the  process  describe  in  this  thesis.  The 
restructuring  could  involve  combining  the  extracted  XML 
fragments  into  a  well-formed  XML  document  based  on  SME. 
This  new  XML  document  could  be  used  as  the  basis  to  build 
future  common  C4I  databases. 

It  needs  to  be  stressed  that  the  XML  based  analysis  and 
comparison  process  described  in  this  thesis  describes  only 
one  way  to  execute  an  XML  based  database  analysis.  XML  and 
XML  related  capabilities  and  tools  provide  the  opportunity 
to  develop  alternative  analysis  and  comparison  methods. 
These  methods  could  include  XML  related  capabilities  and 
tools  like  XSL,  XQuery,  SAX,  and  others.  Each  of  these 
alternative  methods  has  its  own  advantages  and 
disadvantages.  The  use  of  SAX  as  an  alternative  was 
described  in  thesis. 

In  summary,  XML  provides  the  means  to  analyze  and 
compare  heterogeneous  databases.  This  was  proven  through 
the  analysis  and  comparison  of  the  JCDB  and  MIDB  Views.  As 
XML  continues  to  grow,  so  will  the  alternatives  available  to 
analyze  heterogeneous  C4I  databases. 
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APPENDIX  A  -  JCDB  DATABASE  VIEW 


Example  of  extracted  portions  from  data  dictionary  and 
entity  relationship  diagram  [JDDOO] : 


TARGET_ENGAGEMENT_ASSESSMENT  The  table  that  hold  specifics  about  the 

resuits  of  a  TARGET-ENGAGEMENT. 
_ (Battle  Damage  Assessment) 


ATTRIBUTE  NAME 

PHYSICAL 

DEFINITION 

DATA 

NULL 

ATTRIBU 

NAME 

TYPE 

OPTI 

TE 

ON 

entity! 

TARGET- 

ENGMENT 

The  unique 

seria 

NOT 

TARGET 

ENGAGEMENT -END 
index 

ASSES  IN 
DX 

identifier 

that 

represents  a 
specific 

TARGET - 

ENGAGEMENT- 

END 

1 

NULL 

ENGAGEM 
ENT  ASS 
ESSMENT 

TARGET- 

TARGET  E 

The  unique 

inteq 

NOT 

TARGET 

ENGAGEMENT 

identifier 

NGAGE  IN 
DX 

identifier 

that 

represents  a 
specific 

TARGET 

ENGAGEMENT 

er 

NULL 

ENGAGEM 
ENT  ASS 
ESSMENT 

TARGETeng  input 

c_INPUT 

The  MAC 

integ 

NOT 

TARGET 

address  of 

er 

NULL 

ENGAGEM 

the  machine 

ENT  ASS 

creating  the 
record .  The 

ESSMHNT 

unique 

identifier 

that 

represents  a 
specific 

TARGET 

ENGAGEMENT 

TARGET - 

ENGAGEMENT  -  END 
actual  end 
datetime 

ENGAGE  E 
ND_DTTM 

The  end 
datetime  of  a 
TARGET 
engagement . 

datet 

ime 

year 

to 

secon 

d 

NOT 

NULL 

TARGET 
ENGAGEM 
ENT  ASS 
ESSMENT 

T‘*^GT_DISP0_CD  The  code  which  denotes  the  state  of  a  TARGET  after 

it  has  been  ENGAGED. 

—  . 

CODE 

LABEL 


TRGT_DISPO_CD 

TRGT  DIS 
PO_CD 

The  code 
which  denotes 
the  state  of 
a  TARGET 
after  it  has 
been  ENGAGED. 

small 

int 

NOT 

NULL 

TARGET 
ENGAGEM 
ENT  ASS 
ESSMENT 

TARGET - 

ENGAGEMENT - END 
resulting  damage 
quantity 

ENGAGE  D 
MG  PERCN 

T 

The 

percentage  of 
destruction, 
or  other 
desired 
result , 
inflicted 
upon  a  TARGET 
by  a  specific 
TARGET - 
ENGAGEMENT. 
(0-100%) 

decim 

al(5, 

2) 

NULL 

TARGET 
ENGAGEM 
ENT  ASS 
ESSMENT 

TARGET - 
ENGAGEMENT- 
ASSESSMENT 
number  of 
casual ity 
quantity 

NUM  OF  C 
ASUALITI 
ES 

The  number  of 
casualities 
provided  for 
a  TARGET - 
ENGAGEMENT- 
ASSESSMENT. 

NULL 

TARGET 
ENGAGEM 
ENT  ASS 
ESSMENT 
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a>  pi 


APPENDIX  B  -  MIDB  DATABASE  VIEW 


Example  of  extracted  portions  from  data  dictionary  and 
entity  relationship  diagram  [MID98] : 


1.  Table  Name:  TGT__DTL 

2.  Table  Long  Name:  Target 

3.  Description:  This  table  refers  to  a  specific  target  The  target  may  be  a 

desired  mean  point  of  impact  (DMPI),  or  an  area  of  impact. 

4.  Elements: 


AFFILIATION 
AIR_DEF_AREA 
AZIMUTH 
AZIMUTH^REF 
CC  (M) 

CLASS^LVL  (M) 

CODEWORD 
CONDITION  (M) 
CONDITION.AVAIL 
CONTROL_MARK 
COORD  (M) 

COORD^BASIS  (M) 

COORD.DATETIME 

COORD^DATUM  (M) 

COORD^DERIV  (M) 

COORD_DERIV_ACC 

COORD_DERIV_ACC_UM 

COORD_ROA 

COORD^ROA^CONF^LVL 

COORD_ROA_UM 

DATETIME_BEGIN 

DATETIME_CREATED  (M) 

DATETIME_END 

DATETIME^FIRSTJNFO 

DATETIME__LAST_.CHG  (M) 

DATETIME.LASTJNFO 

DECLASS_ON 

DECLASS^ON^DATE 

DMPlJD 

DOMAIN  LVL(M) 

ELEVATION 

ELEVATION__ACC 

ELEVATION_CONF__LVL 

ELEVATION_DATUM 

ELEVATION_DERIV 

ELEVATION_DERIV_ACC 

ELEVATION_DERIV_ACC_UM 

ELEVATION_MSL 

ELEVATION_MSL_ACC 

ELEVATION_MSL_CONF_LVL 

ELEVATION_MSL_DERIV 

ELEVATION_MSL_DERIV_ACC 

ELEVATION_MSL_DERIV_ACC_UM 

ELEVATION_MSL_^UM 

ELEVATION^UM 

EVAL  (M) 

FPA 

GEODETIC_PROD 
Primary  Key(s): 

Foreign  Key{s): 


GEOIDAL_MSL_SEPARATION 

GEOIDAL_MSL_SEPARATION_UM 

GRAPHIC_AGENCY 

GRAPHIC^CC 

GRAPHIC_ED_.DATE 

GRAPHIC_ED__NUM 

GRAPHIC^SCALE 

GRAPHIC^SERIES 

GRAPHIC_SHEET 

HARDNESS 

HEIGHT 

HEIGHT^UM 

ILAT 

!LON 

JMEM_TYPE 
LAST^CHG^USERID  (M) 

LENGTH 
LENGTH^UM 
LOC_NAME 
MIDB^TIMESTAMP  (M) 

MIL^AREA 
MIL_GRID 
MlL__GRID_SYS 
MSN_TYPE 
OPER^STATUS  (M) 

PHOTO^DATE 
POL^SUBDIV 
PROD_LVL_CAP  (M) 
PROD_LVL_REQ  (M) 

RADIUS 
RADIUS^UM 
RECORD_STATUS  (M) 
RECUPJNTRVL 
RECUPJNTRVL_MAX 
RECUPJNTRVL_UM 
RELEASE_MARK 
RES_PROD  (M) 

REVIEW^DATE  (M) 

SHAPE 

SYMBOL^CODE 
TGT_DTL_NAME  (M) 

TGT__DTL_SK  (M) 

UTM 

VERTICAL^ORIENT 

WAC 

WATERBODY 

WIDTH 

WIDTH^UM 

TGT^DTL^SK 

There  are  none  for  this  entity. 
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7. 


1. 

2. 

3. 

4. 


5. 

6. 

7. 


Related  Table(s): 

A  TGT_DTL  many  TGT__DTL_AIMPT_WPNs. 

A  TGT^DTL  many  TGT_DTL_AKAs. 

A  TGT_DTL  many  TGT_DTL__ASSESSs. 

A  TGT__DTL  many  TGT_DTL_TIEs. 

A  TGT_DTL  many  TGT_DTL__TIEs. 

A  TGT^DTL  may  have  many  DOC__MGMT_TIEs,  EQP_ELINT_MODE_TIEs.  EQPJDX  PAR  TIEs 

EQPJDX_TIEs,  EQP_TIEs,  EVENT_TIEs,  FAC^TIEs,  GEO_TlEs,  INDJTIEs,  NET  LINK  DTL  TIEs 
NET_LINK_TIEs,  NET_NODE_TIEs,  OBS_TIEs,  RMK^TIEs,  SIG^TIEs,  SOURCE  TIEs 
TGT_DTL_AIMPT_WPN_TIEs,  TGT_DTL_TIEs,  TGT_llST_TIEs,  TGT^LISTJTIE^ORDER  TIEs. 
TGT_MSN_TIEs.  TGT_OBJ_TIEs,  TGT_SYS_TIEs,  TRACK_TIEs,  UNIT_ALT_LOC_TIEs,  UNIT  TIE. 


Table  Name: 

Table  Long  Name: 

Description: 

and  /  or  strike  assessment. 
Elements: 


TGT_^DTL_ASSESS 
Target  Assessment,  Battle  Damage  or  Strike  Assessment 
This  table  contains  Information  necessary  for  battle  damage 


ASSESS^DATETIME 
ASSESS_TYPE  (M) 

CLASS^LVL  (M) 

CODEWORD 
CONDITION  (M) 

CONDITION^AVAIL 

CONTROL_MARK 

DATETIME^BEGIN 

DATETIME_CREATED  (M) 

DATETIME^END 

DATETIME^FIRSTJNFO 

DATETIME_LAST_CHG  (M) 

DATETIME_LASTJNFO 

DECLASS_ON 

DECLASS__ON_DATE 

DOMAIN^LVL  (M) 

Primary  Key(s): 

Foreign  Key(s): 

TGT_DTL_SK  References:  TGT^DTL 
Related  Table(s):  ^ 


EVAL  (M) 

FPA 

LAST^CHG^USERID  (M) 
MIDB_TIMESTAMP  (M) 
OPER^STATUS  (M) 

PROD  LVL^CAP  (M) 
PROD^LVL^REQ  (M) 
RECORD^STATUS  (M) 
RECUPJNTRVL 
RECUP^INTRVL^MAX 
RECUPJNTRVL^UM 
RELEASE_MARK 
RES_PROD  (M) 
REVIEW^DATE  (M) 
TGT^DTL^ASSESS^SK  (M) 
TGT^DTL^SK  (M) 
TGT_DTL_ASSESS_SK 


A  TGT_DTL_ASSESS  is  associated  with  exactly  one  TGT_DTL. 


1 .  Element  Name: 

2.  Screen  Label: 

3. 

4.  Structure: 

5.  Permissible  Values: 


TGT_DTL_SK 
Not  displayed. 

Description: 

numeric(14,0),  NOT  NULL 


SYSTEM  GENERATED  -  SURROGATE  KEY.  The  unique  database  server 
identifier.  A  numeric  value,  ranging  from  10,000  -  99,999.  The  database  server 
id  will  be  unique  for  each  dbserver  in  the  MIDB  worldwide  network.  The  DB 
Server  ID  is  followed  by  a  one-up-number.  A  one-up-number  series  is 
maintained  for  each  surrogate  key. 

Tables:  TGT^DTL,  TGT_DTL_AIMPT_WPN,  TGT  DTL  AKA. 

TGT_DTL_.ASSESS  ~  “ 


1.  Element  Name: 

2.  Screen  Label: 

3. 


4.  Structure: 

5.  Permissible  Values: 


ASSESS_DATETIME 
ASSESS  DATETIME 

Description:  If  the  ASSESS_TYPE  is  Battle  Damage  Assessment  (BDA) 

this  field  will  contain  the  Time  On  Target  value.  If  the  ASSESS_TYPE  is  Strike 
Assessment  (SA)  this  field  will  contain  the  Time  On  Target  or  the  observation 
time  from  the  report  which  last  caused  a  change. 
varchar(14),  NULL 
RUL_DATETIME 
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[12][90][0-9][0-9] 

[01-12] 

[01-31] 

[00-23] 

[00-59] 

[00-59] 


6. 


Pos.  1-4,  Year 
Pos.  5-6,  Month 
Pos.  7-8,  Day 
Pos.  9-10,  Hour 
Pos.  11-12,  Minute 
Pos.  13-14,  Second 

Positions  must  be  filled  from  the  left.  Positions  on  the  right  may  be  null  filled. 
The  minimum  entry  for  this  field  should  be  a  CENTURY  &  YEAR.  As  more 
information  Is  available  it  should  be  filled.  Conforms  to  the  standard  of  ISO 
8601. 

Tables:  EQP_ASSESS,  FAC_ASSESS,  TGT_DTL_ASSESS, 

TGT_SYS_ASSESS.  UNIT_ASSESS,  UNIT_STRIKE 


1.  Element  Name: 

2.  Screen  Label: 

3. 

4.  Structure: 

5.  Permissible  Values: 
BDA 

SA 

0 

U 

Z 

6. 


ASSESS_TYPE 
ASSESS  TYPE 

Description:  This  field  indicates  whether  the  row  contains  BDA  or  SA 

data. 

char(4),  NOT  NULL 
CON__ASSESS_TYPE 
Battle  Damage  Assessment 
Strike  Assessment 
Other.  Explain  In  Remarks. 

Unknown 

Inconclusive  Analysis 

Tables:  EQP_ASSESS,  FAC_ASSESS,  TGT_DTL_ASSESS, 

TGT_SYS_.ASSESS.  UNIT_.ASSESS,  UNIT^STRIKE 


1 .  Element  Name: 

2.  Screen  Label: 

3. 

4.  Structure: 

5.  Permissible  Values: 

U 

C 

S 

T 

Default  Value: 

6.  Tables: 


CLASS^LVL 
CLASS  LVL 

Description:  Highest  classification  level  of  the  data  contained  within  the 

record. 

char(1),  NOT  NULL 
CON_CLASS__LVL 
Unclassified 
Confidential 
Secret 
Top  secret 
'S’ 

adminsec 
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Modernized  Integrated  Database 

Target 

Target  Assessment/BDAR 
Logical  Data  View 


TGT_DTL 


TGT_DTL_SK 


AFFIUATION 

air_oef_area 

AaMUTH 

AZIMUTTH.REF 

CC(M) 

CIASS_UVL(M) 

CODEWORD 
CONDrnON(M} 
CONOmON.AVAIL 
CONTROL  MARK 
COORD  (M) 

COORD^BAStS  (M) 
COORD_DATETTME 
COORD  DATUM  (M) 

COORD  DBW(M) 

COORD  DERIV  ACC 
COORD_DeRiy_ACC_UM 
COORD_ROA 
COORD  ROA  CONF  LVL 
COORD  RaAL.UM 
DATEnME_BE<31N 
DATETIME^CREATEDCM) 
OATETIME  END 

datetimeIfirst  into 

DATEHME  LAST  W«{M) 

DATETIME^LASTJNFO 

DECIASS.ON 

DeCLASS_OfLDATE 

DMPlJD 

DOMAiN_LVL{M) 
eiB/ATION 
El£VAT10N_.ACC 
aEVATION  CONF  LVL 
ELEVATION  DATUM 
ELEVATION  DERIV 
Et£VAT10NlDeRrV_ACC 
ELEVATION^OERIV  ACC  UM 
ElEVATION  MSL  " 
ELEVATION^MSl^ACC 
ELEVATION.MSI^CC^JF  LVL 
ELEVATION_MSL_D6RIV 
ELEVATlON_MSL_06RIV  ACC 
ELEVATION  MSL  OSW  ACC  UM 
ELEVATION  MSL  UM  "  “ 

ELEVATION  UM 
EVAL(M) 

FPA 

GEODETIC  PROD 


GEaDAL_MSL_SEPARATION 

GEOIDAL^MSL_SEPARATION  UM 

GRAPHtC_A6ENCY 

GRAPHIC  CC 

GRAPHIC  ED  DATE 

GRAPHIC  ED  NUM 

GRAPH!C_SCWJE 

GRAPMC^SERIES 

GRAPHC  SHEET 

HARDNESS 

HEIGHT 

HEIGHT_LW 

ILAT 

ILON 

JMEM_TYPE 

LAST_CHG_USERID{M) 

LENGTH 
LENGTH  UM 
LOC.NA^ 

MIDB_TIMESTAMP(M) 

MIL  AREA 
MIL.GRJD 
MIL_CRID_SVS 
MSN  TVPE 
OPER_STATUS{M) 

PHOTO_DATE 

P0k.SU80IV 

PROD_LVl^CAP(M) 

PROO_LVL  REQ(M) 

RADIUS 
RADIUS  UM 
RECOr6_STATUS(M) 
RECUPJNTRVL 
RECUPJNTRVL  MAX 

recupjntrvlIum 

Ra£ASE_MARK 

RES_PR0D{M) 

REVIEW_0ATE(M) 

SHAPE 

SVMBOL.CODE 

TGT_DTL_NAME(M) 

TGT^DTL  SK(M) 

UTM 

VERTICAL  ORIENT 
WAC 

WATERBODV 
WIDTH 
WIDTH  UM 


TGT  DTT,  AKA 


TGT_DTL_AKA^SiC 

AKA  (M) 

DOMAIN  LVL(M) 

AKA_TYPE(M) 

EVAL(M) 

CLASS  LVL(M) 

FPA 

CODEWORD 

COMTROL.MARK 

OATETIME  BEGIN 

DATETIME  CREATED  (M) 

PR00_L\A.REQ(M) 

DATETIME.END 

RECORD_STATUS(M) 

DATETIME  HRST  INFO 

REIJEASE.MARK 

RES_PROO{M) 

REVIEW_DATE(M> 

OECLASS_ON 

TGT_DTLJVO^SK(M) 

DECLASS.ON.DATE 

TGT_Dn^SK(M) 

TGT  DTI.  ASSFRS 


TGT_DTL_ASSESS  SK 


ASSESS.DATEHME 


EVAL(M} 

FPA 


ASSESS_TYPE(M} 
CLASS_L'W.{M) 
CODEWORD 
CONDITION  (M) 
CONDITION  AVAIL 
CONTROL  MARK 
OATETIME  BEGIN 
DATEnME_CREATED(M) 
OATEnME^ENO 

datetime_firstjnfo 

DATETIME.LAST  CHQ(M) 

datetime.lastjnfo 
declass.on 
DECLASS^ON.DATE 
D0MA1N_LVL  (M) 


lAST.CHQ.USERID  (M) 

MiOe^TIMESTAMP(M) 

0PEJLSTATUS(M) 

PROO_LVl^CAP(M) 

PROp_LVL.REO{M) 

REC0R0.STATUS(M) 

RECUPJNTRVL 

RECUPJNTRVI^MAX 

l«CUPJNTRVV.UM 

RELEAS^MARK 

RES_PROO{M) 

REV1EW_DATE(M) 

T1GT_DTL_ASSESS  SK(M) 

TGT_07l^SK{M) 


TGT  DTL  TIE 

/  '  . 

TGT_DTL_TIE_SK 
Ask)C(M} 
ASS0C_BEGINJWTE 
ASSOC_ENO  CATE 
CLASS_LVL(M) 

CODEWORD 
CONrROL_MARK 
OATEnME_BEGIN 
DATETIMEjCREATEO  (M) 

datetime_end 
DATEnME.FIRSTJNFO 
DATETIliffi.LAST  CHG(M) 
DATETIME  LAST  INFO 
DECLASS  ON 
DECLASSlON_OATE 
D0MAIN_LVL(M) 


EVAL<M} 

LAST_CHG_US£RI0<M) 

MID8_T!MeSTAMP(M) 

PROp_LVL_CAP(M) 

PROO_LVL.REQ0M) 

RECORD  STATUS  (M) 

REI£ASE_MARK 

RES_PROD(M) 

REVIEW.OATE(M} 

TQT_DrL_TIE_SK(M) 

T1E_80OL(M) 

■nE_FROM_SK{M) 

7IE_T0LENTnY(M) 

TIE^TO^SKCM) 


I 
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APPENDIX  C  -  JCDB  XML  DOCUMENT 


<?xinl  version="l .  0  "?> 

<  TARGET - ENGAGEMENT  TARGET_ENGAGE_INDEX= " 5  8  3  2 " > 
<c_INPUT>184</c_INPUT> 

<  PLAN_NUMBER>  6  7 3  9  8  < / PLAN_NUMBER> 

<MSN_NUMBER> 1 6  0 4 1 < /MSN_NUMBER> 

<COA_NUMBER>8  < /COA_NUMBER> 

<CREATING_UNIT_NUM>2 1</CREATING_UNIT_NUM> 
<PHASE_NUMBER>  5  < / PHASE_NUMBER> 

<PIAN_UNIT_NUMBER>2  <  /PLAN_UNIT_NUMBER> 

<TGT_LI ST_TYP_CD> 1 9  < /TGT_LI ST_TYP_CD> 
<ENG_PRECEDENCE_CD>1 < /ENG_PRECEDENCE_CD> 
<EFFECTS_CD>3</EFFECTS_CD> 

<TRGT_STRENGTH_NUM>1 0  < /TRGT_STRENGTH_NUM> 
<TIME_ACQUIRED_DTTM>  010625085623  < /TIME_ACQUIRED_DTTM> 
<TIME_ON_TRGT_DTTM>  010625100000  < /TIME_ON_TRGT_DTTM> 
<ENGAGEMENT_COMMENT>ENGAGE  COORDINATED  W/1®^ 

CAV< /ENGAGEMENT_COMMENT> 

<  EFFECTS_PERCENT  >  7  5  < / EFFECTS_PERCENT > 

<RECORD_STATUS  CODE= "A" > 

<RECORD_STATUS_DTTM>0 1 0625074500< /RECORD_STATUS  DTTM> 
< LABEL > 1 2 < /LABEL > 

< /RECORD_STATUS  > 

< PERCEPTION  PERCEP_REF_INDX= " 8  6 5 9 " > 

<PERCEP_INPUT_ID>4  83  94  < /PERCEP_INPUT_ID> 

<RPRTING_ORG  RPRTING_ORG_ID= " 3  4  73  2 " > 
<RPRTING_ORG_INPUT>29483</RPRTING_ORG_INPUT> 
</RPRTING_ORG> 

<PERCEP_REPRT_DTTM>  01062509 15 00</ PERCEP_REPRT_DTTM> 
<PERCEP_STRT_DTTM>  010625085500< /PERCEP_STRT_DTTM> 
<PERCEP_END_DTTM>  0 10625090000</ PERCEP_END_DTTM> 
<RECORD_STATUS  CODE="A"> 

<RECORD_STATUS_DTTM> 010625091000< /RECORD_STATUS  DTTM> 
<LABEL>10</LABEL>  “ 

< /RECORD_STATUS  > 

</PERCEPTION> 

< TARGET -ENGAGEMENT -ASSESS  ENGMENT_ASSES_INDX= " 1 " > 
<ENGAGE_END_DTTM>  0 106251000  0  0< /ENGAGE_END_DTTM> 
<TRGT_DISPO_CD  CODE="l"> 

<LABEL>6</LABEL> 

< /TRGT_DI SPO_CD> 

<ENGAGE_DMG_PERCNT>  9  0  < /ENGAGE_DMG_PERCNT> 
<NUM_OF_CASUALITIES>15</NUM_OF_CASUALITIES> 
<RECORD_STATUS  CODE= "A" > 

<RECORD_STATUS_DTTM>010625074500</RECORD  STATUS  DTTM> 
<LABEL>12</LABEL>  ~ 

< /RECORD_STATUS  > 
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< PERCEPTION  PERCEP_REF_INDX= " 8 659 " > 

<PERCEP_INPUT_ID>4  83  94 < /PERCEP_INPUT  ID> 

<RPRTING_ORG  RPRTING_ORG_ID= "34732 " >“ 
<RPRTING_0RG_INPIJT>29483</RPRTING  ORG  INPUT> 
</RPRTING_ORG>  ~  “ 

<PERCEP_REPRT_DTTM> 010625101500</ PERCEP_REPRT  DTTM> 

<  PERCEP_STRT_DTTM>  010625100000</ PERCEP_STRT_DTTM> 
<PERCEP_END_DTTM>010625100500</PERCEP  END  DTTM> 
<RECORD_STATUS  CODE="A">  “  “ 

<RECORD_STATUS_DTTM>010625101500</RECORD  STATUS  DTTM> 
<LABEL>10</LABEL>  ~  “ 

< /RECORD_STATUS  > 

</PERCEPTION> 

< /TARGET - ENGAGEMENT - AS  SESS  > 

<TARGET-ENGAGEMENT-ASSESS  ENGMENT_ASSES_INDX= " 2 " > 
<ENGAGE_END_DTTM>010625121500</ENGAGE  END  DTTM> 
<TRGT_DISPO_CD  CODE="l">  “  “ 

< LABEL > 6 </ LABEL > 

</TRGT_DISPO_CD> 

<ENGAGE_DMG_PERCNT>8  0  <  /ENGAGE_DMG_PERCNT> 

< NUM_OF_CAS UAL I T I E S > 1 0 < / NUM_0 F_CAS UAL I T I E S > 
<RECORD_STATUS  CODE= "A" > 

<RECORD_STATUS_DTTM> 010625123000< /RECORD  STATUS  DTTM> 
<LABEL>12</LABEL>  “  ~ 

< /RECORD_STATUS  > 

< PERCEPTION  PERCEP_REF_INDX= " 8659 " > 

<PERCEP_INPUT_ID>4 83 94 </PERCEP_INPUT_ID> 

<RPRTING_ORG  RPRTING_ORG_ID= " 3  4  73 2 " > 
<RPRTING_ORG_INPUT>29483</RPRTING  ORG  INPUT> 
</RPRTING_ORG>  “  “ 

< PERCEP_REPRT_DTTM> 0 10625124000</ PERCEP_REPRT  DTTM> 

<  PERCEP_STRT_DTTM  >010625122000</ PERCE P_S TRT_DTTM> 
<PERCEP_END_DTTM>010625123000</PERCEP  END  DTTM> 
<RECORD_STATUS  CODE="A">  “  ~ 

<RECORD_STATUS_DTTM>010625124000</RECORD  STATUS  DTTM> 
<LABEL>10</LABEL>  ~  ~ 

< /RECORD_STATUS  > 

</PERCEPTION> 

< /TARGET - ENGAGEMENT -ASSESS > 

</TARGET-ENGAGEMENT> 
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APPENDIX  D  -  MIDB  XML  DOCUMENT 


<?xml  version="l . 0"?> 

<  TARGET  TGT_DTL_SK= " 1 9  9 5  4 " > 
<AFFILIATION>H</AFFILIATION> 

<  COUNTRY> I Q< / COUNTRY> 

<  CLAS  S_LVL  >U< / CLAS S_LVL > 

<CONDITION>CCD</CONDITION> 

<COORD>234853658S1453834674W</COORD> 

<  COORD_BAS  I S  >GA<  /  COORD_BAS  I S  > 

<  COORD_DATUM>BUP< /COORD_DATUM> 

<  COORD_DERI V>K< /COORD_DERI V> 

<DATETIME_CREATED> 1 9650229122543< /DATETIME_CREATED> 
<DATETIME_LAST_CHG> 1 9650229161445< /DATETIME_LAST_CHG> 
<DOMAIN_LVL>CO< /DOMAIN_LVL> 

<EVAL>1</EVAL> 

<LAST_CHG_USERID>DJFGEIDG</LAST_CHG_USERID> 

<MIDB_TIMESTAMP>2347</MIDB_TIMESTAMP> 

<OPER_STATUS >RDO < /OPER_STATUS > 

<  PROD_LVL_CAP  >  S  < / PROD_LVL_CAP > 

<  PROD_LVL_REQ  >  S  < / PROD_LVL_REQ > 

<RECORD_STATUS  >A< /RECORD_STATUS  > 
<RES_PROD>XX</RES_PROD> 

<REVIEW_DATE>1 965  02  2  9170210< /REVIEW_DATE> 

<  TGT_DTL_NAME  >BADGUYS  < / TGT_DTL_NAME > 

<  TGT_DTL_AKA  TGT_DTL_AKA_SK= " 8  7  4  4  2 " > 
<AKA>REALLYBADGUYS< /AKA> 

<AKA_TYPE  >OAP< /AKA_TYPE  > 

<CLASS_LVL>U< /CLASS_LVL> 

<DATETIME_CREATED> 1 9650301063043< /DATETIME_CREATED> 
<DATETIME_LAST_CHG> 19650301065545< /DATETIME_LAST_CHG> 
<DOMAIN_LVL>CO< /DOMAIN_LVL > 

<EVAL>1</EVAL> 

<LAST_CHG_USERID >H JGFGYVT< / LAS T_CHG_USERID> 
<MIDB_TIMESTAMP>4345</MIDB_TIMESTAMP> 

<OPER_STATUS  >RD0  < /OPER_STATUS  > 

<  PROD_LVL_CAP  >  S  < / PROD_LVL_CAP > 

<PROD_LVL_REQ>S< / PROD_LVL_REQ> 

<RECORD_STATUS  >A< /RECORD_STATUS  > 

<RES_PROD>XX< /RES_PROD> 

<REVIEW_DATE> 1 9650310120000< /REVI EW_DATE  > 
</TGT_DTL_AKA> 

<TGT_DTL_ASSESS  TGT_DTL_ASSESS_SK= "24373" > 
<ASSESS_TYPE>BDA</ASSESS_TYPE> 

<  CLASS_LVL  >U< / CLAS S_LVL  > 

< CODEWORD > 0 </ CODEWORD > 

<CONDITION>DST</CONDITION> 

<CONDITION_AVAIL>DMG</CONDITION_AVAIL> 
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<CONTROL_MARK>NF< /CONTROL_MARK> 

<DATETIME_CREATED>19 65 03  02 1 832 12 </DATETIME  CREATED> 
<DATETIME_LAST_CHG>19650302192354</DATETIME  LAST  CHG> 
<DOMAIN_LVL>CO</DOMAIN_LVL>  “  ~ 

<EVAL>8</EVAL> 

<FPA>EOB</FPA> 

<LAST_CHG_USERID>VGFGHJFT</LAST_CHG_USERID> 
<MIDB_TIMESTAMP>7654 < /MIDB_TIMESTAMP> 

<OPER_STATUS  >RD3  < /OPER_STATUS  > 

<  PROD_LVL_CAP  >  S  < / PROD_LVL_CAP > 

<  PROD_LVL_REQ>  S< / PROD_LVL_REQ  > 

<RECORD_STATUS  >A< /RECORD_STATUS  > 

<RECUP_INTRVL>1 0  0  0  < /RECUP_INTRVL> 

<RECUP_INTRVL_MAX> 1 5  0  0  < /RECUP_INTRVL_MAX> 
<RECUP_INTRVL_UM>  14DAY< /RECUP_INTRVL  UM> 
<RELEASE_MARK>BZ</RELEASE_MARK>  ~ 

<  RES_PROD  >  Z  < /RES_PROD > 

<REVIEW_DATE>1 965 032 0 12 0  0 0 0 < /REVIEW  DATE> 
</TGT_DTL_ASSESS>  “ 

<TGT_DTL_ASSESS  TGT_DTL_ASSESS_SK= " 3 75 84 " > 
<ASSESS_TYPE>BDA</ASSESS_TYPE> 

<  CLASS_LVL>U< / CLAS  S_LVL> 

<  CODEWORD  >  0  < / CODEWORD > 

<CONDITION>DST</CONDITION> 

<  COND I T I ON_A VA IL>DMG</CONDITI ON_AVAI L > 

<  CONTROL_MARK>NF  < / CONTROL_MARK > 

<DATETIME_CREATED> 1 9650320120000< /DATETIME_CREATED> 
<DATETIME_LAST_CHG>19650320193110</DATETIME  LAST  CHG> 
<DOMAIN_LVL>CO</DOMAIN_LVL>  “  ~ 

<EVAL>8</EVAL> 

<FPA>EOB</FPA> 

<LAST_CHG_USERID>JUERHWC</LAST_CHG_USERID> 
<MIDB_TIMESTAMP>  8  5  6  6  < /MIDB_TIMESTAMP> 

<OPER_STATUS  >RD3  < /OPER_STATUS  > 

< PROD_LVL_CAP > S < / PROD_LVL_CAP > 

<  PROD_LVL_REQ  >  S  < / PROD_LVL_REQ > 

<RECORD_STATUS  >A< /RECORD_STATUS  > 

<RECUP_INTRVL>2  5  0  0  < /RECUP_INTRVL> 

<RECUP_INTRVL_MAX>  5  0  0  0  < /RECUP_INTRVL_MAK> 
<RECUP_INTRVL_UM>3  0DAY< /RECUP_INTRVL_UM> 

<  RELEASE_MARK>BZ< /RELEAS E_MARK> 

<  RES_PROD  >  Z  < /RES_PROD  > 

< REVI EW_DATE >19650322120000</ RE VI EW  DATE > 
</TGT_DTL_ASSESS>  “ 

<TGT_DTL_TIE  TGT_DTL_TIE_SK="34578 " > 

<ASSOC>AZ</ASSOC> 

<CLASS_LVL>U< /CLASS_LVL> 

<DATETIME_CREATED> 19650229150150< /DATETIME  CREATED> 
<DATETIME_LAST_CHG>19650229161212</DATETIME  LAST  CHG> 
<DOMAIN_LVL>CO</DOMAIN_LVL>  ~  “ 

<EVAL>1</EVAL> 
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<IiA.ST_CHG_USERID>BNVVTF</LAST_CHG_USERID> 
<MIDB_TIMESTAMP>  9  8  7  9  < /MIDB_TIMESTAMP> 
<OPER_STATUS >RDO < /OPER_STATUS > 
<PROD_LVL_CAP>S<  /PROD_LVL_CAP> 

<  PROD_LVL_REQ  >  S  < / PROD_LVL_REQ > 
<RECORD_STATUS  >A<  /RECORD_STATUS  > 
<RES_PROD>XX< /RES_PROD> 

<  RE VI EW_DATE  >19650315120000</ REVI E W_DATE  > 
<TIE_BOOL>0</TIE_BOOL> 

<TI E_FR0M_SK>2  3  4  2  9  < / TI E_FROM_S  K> 

<  TI E_TO_ENTI T Y>TRG_DTL < / T I E_TO_ENT I TY > 
</TGT_DTL_TIE> 

</ TARGET > 
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APPENDIX  E  -  ANALYSIS  AND  MANIPDLATION  CODE 


<html> 

<head> 

<!--  Code  adapted  from  code  provided  in  XML  IE5  (see  references). 
<title>Listing  XML  Document  Nodes  and  Attributes</title> 

<style  type="text/css"> 

BODY  {font-family:Tahoma, Verdana, Arial, sans-serif ;  font-size : 12px;  font 
weight : normal } 

.intro  {font-family:Tahoma, Verdana, Arial, sans-serif ;  font-size:14px; 
font-weight :bold} 

</style> 

<!--  The  SRC  will  have  to  be  changed  to  name  of  XML  file  to  be  searched 
<XML  ID=”domSearchList"  SRC=" j cdbxml .xml "></XML> 

<i--  Code  built  in  JavaScript  ^ 

<SCRIPT  LANGUAGE= " JavaScript ” > 

<!-- 

//Function  parses  and  checks  for  errors . 

//Note  the  parseError  is  a  Microsoft  extention  to  the  W3C  DOM. 

//It  is  the  only  Microsoft  extention  used  in  this  code. 

//All  other  APIs  used  are  included  in  W3C  DOM  Recommendation  #1. 
function  parseXMLO  { 

//Develops  DOM  from  XML. 

objXMLData  =  document . all [ 'domS ear chList ']  ; 
if  (objXMLData. parseError . errorCode  1=  0)  { 

alert (' Invalid  XML  file:  '  +  ob jXMLDat a. parseError .reason) ; 
return; 

} 

//Modify  "XXXXX"  in  searchDocument (objXMLData,  "XXXXX") 

//to  desired  search  key.  Note:  Case  .sensitivity  is  iir^ortant!! 
divResults  .  innerHTML  =  searchDocument  (objXMLData,  *' TARGET -ENGAGEMENT - 
ASSESS") ; 

} 

//Primary  function  that  executes  search  of  DOM 
function  searchDocument (sour ceDoc,  searchKey)  { 

//  declare  local  variables 

var  objNode; 

var  strNodes  =  ' ' ; 

var  I  «  0; 

var  listNodes  =  ' ' ; 

var  f oundNode  =  ' ' ; 

var  clonedNode; 

//Creates  XML  DOM  Fragment. 


123 


var  objFrag; 

objFrag  =  sourceDoc.createDocumentFragment () ; 

/ /  Finds  the  root  of  XML  document . 
theRoot  =  sourceDoc.documentElement ; 

//  Search  for  authors. 

//  Develops  a  list  of  Nodes  matching  search  key. 
listNodes  =  theRoot .getElementsByTagName (searchKey) ; 

//  Check  and  show  alert  on  how  many  found. 

//  listNodes. length  provides  number  of  nodes  in  list, 
if  (listNodes . length  >0)  { 

alert  ('Found'  +  listNodes . length  +  searchKey); 

else  { 

alert  ('Found'  +  listNodes .  length  -f  searchKey); 

alert  ('Check  and  re-enter  Search  Key.  Note  case  sensitivity  is 
important ! ! ' ) ; 

} 

//  Loops  through  list  of  authors, 
for  (I  =  0;  I  <  listNodes . length;  I++) 

{ 

//Sets  located  node. 
foundNode  =  listNodes (I) ; 

//Clones  (copies)  node  ("true"  attribute  results  in  all  children 
being  cloned) . 

objNode  =  foundNode . cloneNode (true) ; 

//Appends  cloned  node  (and  children)  to  XML  fragment) 
objFrag. appendChi Id (objNode) ; 

//Loop  repeats  until  nodeList  is  exhausted. 

} 

//Provides  quick  output  of  built  XML  fragment, 
alert  (objFrag. xml) ; 

/ /  Loop  through  list  of  authors  again  to  breakdown  fragment  and  then 
build  output. 

for  (1=0;  I  <  listNodes . length;  I++) 

{ 

foundNode  =  listNodes (I) ; 

//strNode  is  simple  text  variable  that  is  continuously  appended  to 
build  output. 

//Calls  showChildNodes  function  that  decomposes  node. 

//Also  checks  for  attributes  and  checks  for  child  nodes. 

//^f  child  nodes  exist,  the  showChildNodes  calls  the  shows Chi IdNodes 
function  again. 

//This  recursive  function  call  continues  until  no  are  children  left. 
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//Then  returns  strNode. 
strNodes  +=  showChildNodes (foundNode,  0) ; 
strNodes  +=  '</B><BR>'  +  '</B><BR>'; 

} 

return  strNodes; 

} 

//objNode  provides  the  top  level  foundNode  that  is  to  be  decomposed. 
//intLevel  provide  the  indentation  detail  as  strNode  is  being  built, 
function  showChildNodes (objNode,  intLevel)  { 
var  strNodes  =  ' ' ; 
var  intCount  =  0; 
var  intNode  =  0; 


//  Gets  the  values  for  this  node. 

strNodes  +=  get  Indent  (intLevel)  +  '<B>'  +  objNode  .nodeName 

+  '</B>  &nbsp;  Type:  <B>'  +  ge tNode Type (objNode .nodeType) 

+  '</B>  Scnbsp;  Value:  <B>'  +  objNode .  node  Value  +  '</B><BR>'; 


//  Checks  for  any  attributes . 
objAttrList  =  objNode . attributes ; 
if  (objAttrList  !=  null)  { 

intCount  =  objAttrList . length; 
if  (intCount  >  0)  { 

//  For  each  attribute,  displays  the  attribute  information, 
for  (intAttr  =  0;  intAttr  <  intCount;  intAttr++)  { 
strNodes  +=  get Indent (intLevel  +  1)  +  '<B>' 

+  ObjAttrList (intAttr) . nodeName  +  '</B>  &nbsp;  Type: 


<B>' 


+  getNodeType (objAttrList (intAttr) .nodeType) 

+  '</B>  &nbsp;  Value:  <B>' 

+  ObjAttrList (intAttr) . nodeValue  +  '</B><BR>'; 

} 

} 

} 


//  Checks  for  any  child  nodes. 
intCoiint  =  objNode .  childNodes .  length; 
if  (intCount  >0)  { 

//  For  each  child  node,  display  the  node,  attributes  and  its  child 
node  information. 

for  (intNode  =  0;  intNode  <  intCount;  intNode++)  { 

//Recursive  showChildNodes  function  call. 

strNodes  +=  showChildNodes (objNode . childNodes (intNode) ,  intLevel  + 

1); 

} 

} 

re  turn  s  t  rNode  s ; 

} 
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//The  getNodeType  (intType)  function  returns  detail  on  type  of  node. 
//The  DOM  API  provides  for  several  different  types  of  nodes, 
function  getNodeType (intType)  { 
switch  (intType)  { 
case  1: 

return  "ELEMENT  (1)"; 
break; 
case  2 : 

return  "ATTRIBUTE  (2)"; 
break; 
case  3 : 

return  "TEXT  (3)"; 
break; 
case  4 : 

return  "CDATA  SECTION  (4)"; 
break; 
case  5: 

return  "ENTITY  REFERENCE  (5)"; 
break; 
case  6: 

return  "ENTITY  (6)"; 
break; 
case  7: 

return  "PROCESSING  INSTRUCTION  (7)"; 
break; 
case  8 : 

return  " COMMENT  ( 8 ) " ; 
break; 
case  9: 

return  "DOCUMENT  (9)"; 
break; 
case  10: 

return  "DOCUMENT  TYPE  (10)"; 
break; 
case  11: 

return  "DOCUMENT  FRAGMENT  (11)"; 
break; 
case  12 : 

return  "NOTATION  (12)"; 

} 

} 

//getindent  Function  call  used  to  improve  readability  of  strNode  output. 

//Children  nodes  are  indented  from  parents. 

function  getindent (intLevel)  { 
var  str Indent  =  ' ' ; 

for  (intlndent  =  0;  intindent  <  intLevel;  intlndent++) 
strindent  +=  '  &nbsp ;  &nbsp ;  &nbsp ;  &:nbsp ;  &nbsp ; " 
return  strindent; 

} 
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//^ 

</SCRIPT> 

</head> 

<! —  HTML  is  simply  used  to  facilitate  calling  of  functions  -> 

<!--  and  output  of  strNode 

<body  BGCOLOR=''#FFFFFF"  ONLOAD="parseXML  ()  "> 

<SPAN  CIiASS=intro>Located  and  Decomposed  Elements  and  Children</SPAN><P> 

<!--  to  insert  the  results  of  parsing  the  object  model 
<DIV  ID="divResults">Parsing  XML  file  ...</DIV> 

<!--  Button  function  below  displays  original  XML  file  being  examined. 
<!--  Will  have  to  change  name  of  XML  file  to  one  to  be  examined.  -> 

<!--  Make  sure  XML  file  is  contained  in  same  folder  as  this  file. 

<!--  CAUTION  CAUTION  CAUTION  -> 

<!--  If  examining  extremely  large  XML  files  built  from  large  databases 
<!--  like  JCDB  or  MIDB. 

<!--  Best  to  change  Button  call  to  a  comment  line  like  the  one  below 

<!--  < INPUT  TYPE=" BUTTON"  VALUE= " &nbsp ;  &nbsp;  &nbsp; " 

ONCLICK= " location . href = ' onebook . xml ' " > 

&nbsp; Display  the  XML 

<HR><B>&nbsp;  &nbsp;  &nbsp; 

<INPDT  TYPE= "BUTTON"  VALUE="&nbsp;  &nbsp;  &nbsp;" 

ONCLICK= "location . href = ' JCDBXML . xml ' " > 

&nbsp; Display  the  XML 
</B><P> 

</body> 

</html> 
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APPENDIX  F  -  JCDB  ANALYSIS  OUTPUT 


Located  and  Decomposed  Elements  and  Children 

TARGET-ENGAGEMENT-ASSESS  Type:  ELEMENT  (1)  Value:  null 
ENGMENT_ASSES_INDX  Type:  ATTRIBUTE  (2)  Value:  1 
ENGAGE_END_DTTM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  010625100000 
TRGT_DISPO_CD  Type:  ELEMENT  (1)  Value:  null 
CODE  Type:  ATTRIBUTE  (2)  Value:  1 
LABEL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  6 
ENGAGE_DMG_PERCNT  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  90 
NUM_OF_CASUALITIES  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  15 
RECORD_STATUS  Type:  ELEMENT  (1)  Value:  null 
CODE  Type:  ATTRIBUTE  (2)  Value:  A 

RECORD_STATUS_DTTM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  010625074500 
LABEL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  12 
PERCEPTION  Type:  ELEMENT  (1)  Value:  null 

PERCEP_REF_INDX  Type:  ATTRIBUTE  (2)  Value:  8659 
PERCEP_INPUT_ID  Type :  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  48394 
RPRTING_ORG  Type:  ELEMENT  (1)  Value:  null 

RPRTING_ORG_ID  Type:  ATTRIBUTE  (2)  Value:  34732 
RPRTING_ORG_INPUT  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  29483 
PERCEP_REPRT_DTTM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  010625101500 
PERCEP_STRT_DTTM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  010625100000 
PERCEP_END_DTTM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  010625100500 
RECORD_STATUS  Type:  ELEMENT  (1)  Value:  null 
CODE  Type:  ATTRIBUTE  (2)  Value:  A 
RECORD_STATUS_DTTM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  010625101500 
LABEL  Type:  ELEMENT  (1)  Value:  null 
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#text  Type:  TEXT  (3)  Value:  10 


TARGET-ENGAGEMENT-ASSESS  Type:  ELEMENT  (1)  Value:  null 
ENCT5ENT_ASSES_INDX  Type:  ATTRIBUTE  (2)  Value:  2 
ENGAGE_END_DTTM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  010625121500 
TRGT_DISPO_CD  Type:  ELEMENT  (1)  Value:  null 
CODE  Type:  ATTRIBUTE  (2)  Value:  1 
LABEL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  6 
ENGAGE_DMG_PERCNT  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  80 
NDM_OF_CASUALITIES  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  10 
RECORD_STATUS  Type:  ELEMENT  (1)  Value:  null 
CODE  Type:  ATTRIBUTE  (2)  Value:  A 
RECORD_STATUS_DTTM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  010625123000 
LABEL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  12 
PERCEPTION  Type:  ELEMENT  (1)  Value:  null 

PERCEP_REF_INDX  Type:  ATTRIBUTE  (2)  Value:  8659 
PERCEP_INPUT_ID  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  48394 
RPRTING_ORG  Type:  ELEMENT  (1)  Value:  null 

RPRTlNG_ORG_ID  Type:  ATTRIBUTE  (2)  Value:  34732 
RPRTING_ORG_INPUT  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  29483 
PERCEP_REPRT_DTTM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  010625124000 
PERCEP_STRT_DTTM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  010625122000 
PERCEP_END_DTTM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  010625123000 
RECORD_STATUS  Type:  ELEMENT  (1)  Value:  null 
CODE  Type:  ATTRIBUTE  (2)  Value:  A 
RECORD_STATUS_DTTM  Type :  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  010625124000 
LABEL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  10 
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APPENDIX  G  -  MIDB  ANALYSIS  OUTPUT 


Located  and  Decomposed  Elements  and  Children 
TGT_DTL_ASSESS  Type:  ELEMENT  (1)  Value:  null 

TGT_DTL_ASSESS_SK  Type:  ATTRIBUTE  (2)  Value:  24373 
ASSESS_TYPE  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  BDA 
CLASS_LVL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  U 
CODEWORD  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  0 
CONDITION  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  DST 
CONDITION_AVAIL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  DMG 
CONTROL_MARK  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  NF 
DATETIME_CREATED  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  19650302183212 
DATETIME_LAST_CHG  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  19650302192354 
DOMAIN_LVL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  CO 
EVAL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  8 
FPA  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  EOB 
LAST_CHG_USERID  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  VGFGHJFT 
MIDB_TIMESTAMP  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  7654 
OPER_STATUS  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  RD3 
PROD_LVL_CAP  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  S 
PROD_LVL_REQ  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  S 
RECORD_STATUS  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  A 
RECUP_INTRVL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  1000 
RECUP_INTRVL_MAX  Type:  ELEMENT  (1)  Value:  null 
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#text  Type:  TEXT  (3)  Value:  1500 
RECITP_INTRVL_UM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  14DAY 
RELEASE_MARK  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  BZ 
RES_PROD  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  Z 
REVIEW_DATE  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  19650320120000 


TGT_DTL_ASSESS  Type:  ELEMENT  (1)  Value:  null 

TGT_DTL_ASSESS_SK  Type:  ATTRIBUTE  (2)  Value:  37584 
ASSESS_TYPE  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  BDA 
CIiASS_LVL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  U 
CODEWORD  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  0 
CONDITION  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  DST 
CONDITION_AVAIL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  DMG 
CONTROL_MARK  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  NP 
DATETIME_CREATED  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  19650320120000 
DATETIME_LAST_CHG  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  19650320193110 
DOMAIN_LVL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  CO 
EVAL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  8 
FPA  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  EOB 
IiAST_CHG_USERID  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  JUERHWC 
MIDB_TIMESTAMP  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  8566 
OPER_STATUS  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  RD3 
PROD_LVL_CAP  Type:  ELEMENT  (1)  Value:  null 
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#text  Type:  TEXT  (3)  Value:  S 
PROD_LVL_REQ  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  S 
RECORD_STATUS  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  A 
RECUP_INTRVL  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  2500 
RECUP_INTRVL_MAX  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  5000 
RECtrP_INTRVL_UM  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  30DAY 
RELEASE_MARK  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  BZ 
RES_PROD  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  Z 
REVIEW_DATE  Type:  ELEMENT  (1)  Value:  null 
#text  Type:  TEXT  (3)  Value:  19650322120000 
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GLOSSARY 


ABCS 

AFATDS 

API 

BDAR 

C2 

C4I 

COI 

COP 

COTS 

CTP 

DBMS 

DIICOE 

DISA 

DoD 

DOM 

DTD 

GCCS 

GML 

HTML 

IDEFIX 

ISO 

JBC 

JBMI 

JCDB 

MIDB 

MSXML 

NPS 

ODBC 

OODB 

OODBMS 

OS-OTG 

R&R 

RDBMS 

SAX 

SAX 

SGML 

SHADE 

SME 

SMEs 

SQL 

SQL 

TARDEC 

TDBM 

URI 


Army  Battlefield  Command  System 

The  Advanced  Field  Artillery  Tactical  Data  System 
Application  Programming  Interface 
Battle  Damage  Assessment  Report 
Command  and  Control 

Command,  Control,  Communication,  Computers,  and 

Intelligence 

Community  of  Interest 

Common  Operational  Picture 

Commercial -Of f -The -Shelf 

Common  Tactical  Picture 

Database  Management  System 

Defense  Information  Infrastructure  Common  Operating 
Environment 

Defense  Information  Systems  Agency 

Department  of  Defense 

Document  Object  Model 

Document  Type  Definition 

Global  Command  and  Control  System 

Generalized  Markup  Language 

Hypertext  Markup  Language 

Integrated,  Imagery  and  Intelligence 

Integration  Definition  for  Information  Modeling 

International  Organization  for  Standardization 

Joint  Battle  Center 

Joint  Battle  Management  Initiative 

Joint  Common  Database 

Modernized  Intelligence  Database 

Microsoft  XML  Parser 

Naval  Postgraduate  School 

Open  Database  Connectivity 

Object-Oriented  Database 

Object  Oriented  Database  Management  System 
Over  the  Horizon  Targeting  Gold 
Registry  and  Repository 
Relational  Database  Management  System 
Simple  API  for  XML 
Simple  API  for  XML 

Standardized  Generalized  Markup  Language 

SHAred  Data  Engineering 

Subject  Matter  Expert 

Subject  Matter  Experts 

Structured  Query  Language 

Structured  Query  Language 

Tank- Automotive  Research,  Development  and 
Engineering  Center 
Track  Database  Manager 
Unified  Resource  Identifier 
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USMTF 

VMF 

W3C 

XML 

XSL 

XSLT 


United  States  Message  Text  Format 

Variable  Message  Format 

World  Wide  Web  Consortium 

Extensible  Markup  Language 

Extensible  Stylesheet  Language 

Extensible  Stylesheet  Language  Transformation 
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